How to achieve consistent estimates



At the iHub, we work on multiple projects with multiple teams sometimes all at once. The process of software estimation is perilous at best even when there is only one team working on it.

Our situation is even more complex with individual developers serving in multiple teams and sometimes in a team of one!

Getting to consistent estimates across this various scenarios is not easy. In this entry, I will share some of the tips we have found to work in the past.

Find a common denominator

Estimates usually come in two flavours, days or story points. Ideally, estimates should always be in story points from which you derive days of work.

Unfortunately for most people, story points are just not intuitive. This means they make a great tool for establishing the work to be done but not a particularly great one for communicating the same.

Thus to establish consistency in communication, all our estimates are communicated in ideal days.

To be sure, this has come back to bite us once or twice where the client confused ideal days with calendar days but all in all the gains in shared understanding made for a worthwhile trade-off.

Review stories from similar past projects

Hofstadter’s law states:

It always takes longer than you expect, even when you take into account Hofstadter's Law.

Obviously, this is not a physical law, but you would do well to be mindful of it.

Thankfully, well measured past projects cut through our biases and reflect on us the truth.

For example, one of the more successful projects we worked on, our initial estimate was 5 months, as an e-commerce platform we were sure we understood everything related to it. In the end, it took 8 months from the first commit to a fundable version.

In current projects, we keep this hard lesson in mind as we think of the estimates we provide to clients. Particularly if a client wants a similar application, we now know how long it takes to get it done.

By having such a repository of past projects and the time it took to complete it, disparate teams can base their estimates on them and come up with consistent results.

Estimate some stories together

I expect developers to be very good at writing clean code that has a solid architecture with minimal coupling. I am however quite forgiving if they are not exactly masters of the black art of software estimation.

Still, the more estimators you have, the better. Groups will do wonders to the quality of the estimate.

Even if you will need the developers or individual teams to do their own estimates, it still makes sense to have a session where you work on it all together first.

How do you ensure consistent estimates in your organization? Talk to me in the comment section below or on my twitter @jchex



Fostering a culture of team learning



Recently, we were sharing our experiences with my friend. He mentioned a statement his boss used to tell him when he worked at craft silicon.

I would rather hire three average developers than one rockstar developer. Within six months they will have delivered more.

Obviously, this rings true to my team orientated mind.

Yet such delivery does not just happen automatically. In the same way, individuals need to learn, so do teams.

Anita et al describe why some teams are smarter than others

In this entry, I will be looking at what you can do to stimulate learning in your own developer teams.

Break down communication barriers

As companies grow, the amount of paper work grows as well. This is not necessarily a bad thing, it implies the organization is codifying its knowledge thereby reducing rework.

For example, if you are hiring 8 – 10 developers every month it probably makes a lot of sense to have the on boarding process in a document.

The problem comes when communication happens primarily via documents.

The key here is to challenge yourself not to create a policy every time something goes wrong. Policies are only useful when the situation reoccurs many times within the course of your business.

You maybe intimately aware of agile’s face to face communication principle, yet the allure of beautifully detailed dashboard is guaranteed to get to any manager.

Don’t get carried away, there is such a thing as, over collaboration, constant communication also disrupts creative work.

If you do manage to hit the balance between process and communication the next biggest challenge is to ensure the team is kept intact and members are learning each other’s vocabulary

Build whole team responsibility

I find it surprising some people deliberately pigeonhole themselves with meaningless titles; “PHP developer”, “Python developer” etc. Of what use is your language to the business?

Clients care about having their problems solved. This means everyone in the team is a problem solver first then whatever other titles they chose.

In this mindset, everyone owns the outcome, not just the tasks they are working on. This means if as an individual you do everything right but the project still failed, then you also failed!

The more everyone has been involved in everything the more responsibility they will feel towards its success.

Lynda Gratton puts it as:

    working with other people was never more exciting and exhilarating and when you knew deep in your heart that what you were jointly achieving was important and purposeful

Capture useful knowledge

Let’s start with some timeless advice from Seneca

It is the mind which is tranquil and free from care which can roam through all the stages of its life: the minds of the preoccupied, as if harnessed in a yoke, cannot turn round and look behind them. So their lives vanish into an abyss; and just as it is no use pouring any amount of liquid into a container without a bottom to catch and hold it, so it does not matter how much time we are given if there is nowhere for it to settle; it escapes through the cracks and holes of the mind.

Here he was referring to the people who waste their time. But I feel it equally applies to those who waste their experience.

Whenever you work on a project, there is always something new to learn. Maybe you just figured out the lighting in meeting room A does not allow for easy projection. How do you capture this knowledge? How do you ensure no one else does a client demo in that room? If you encounter a rare bug in one of your core libraries, what do you do about it?

Reconciliation is a useful concept in this regard. Whenever you are done with a sprint, a project or even a day. Consider what did you expect to happen vs what actually happened.

How do you foster team learning in your own organization?  Talk to me in the comment section below or on my twitter @jchex



Working with sceptics to new practises



There comes a time when you must introduce new practises or processes to your team.

Don’t expect it to be all smooth sailing, especially for well-established teams. They will question it. Unfortunately, it’s very easy to convince yourself that by virtue of your title you can push the practice and have it adopted whole heartedly

What you want to think of is the distinction between compliance and commitment.

Here are some of my suggestions for working with your sceptics.

Let them see the benefits

It’s bad enough you are introducing a new system for them to use it better work!

In leadership, it’s easy to assume what you know is correct and others are wrong. This dangerous assumption means you push practices that have no other value besides inflating your own ego.

If the practice is beneficial, then let the people see it. By adopting the practice, you should be able to show them via anecdotal evidence of its success and how it benefits them.

Provide training

The knowledge that is painfully obvious to you is likely foreign and unintuitive to your team.

Hanlon’s razor captures it beautifully:

Don't assume bad intentions over neglect and misunderstanding.

Training can be very useful in this respect, by running even an hour session with the team showing them how the process is done, you can make a lot of headway in getting them to adopt it.

Celebrate vocal sceptics

There is always that thorn to your flesh. The individual who is very vocal about your changes and how stupid they are.

The natural human reaction to such hostility is to close them out or attack them.

I suggest you instead keep an open mind and assume the individual is questioning the methods not you as an individual.

As such, invite them to all relevant process improvement sessions, let them air their views. Genuinely take them into consideration and address what can be addressed.

Hopefully, they can become your champions, if not, then maybe they can disagree but commit.

Have Backbone; Disagree and Commit. “Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.”

    ~ Jeff Bezos

Challenge them to do their best so that they can prove you wrong

All processes introduce a level of drag into the system, in effect what was getting done, gets done slower. The benefit usually lies in improved quality and less rework.

That’s of course if your process is a good one, there is always the chance you are wrong and unnecessarily burdening your team.

So teach the team the easiest way to shove it in your face is to do their best at this new practice and if no benefit accrues, you will be forced to reconsider.

While obviously a dangerous move, they can choose sabotage, if it works it will provide compelling evidence, enough to move them from compliance to commitment.

Show don’t tell

This is a particularly useful heuristic in many areas of life including the change in the process.

One of the great commandments of science is:

Mistrust arguments from authority

You want your team constantly engaged in a constructive disagreement with you, that’s how you get the most creative ideas out of them. If they become “yes men” your innovation capacity effectively shrinks to just one person, you.

By allowing for disagreement you then have the chance to show your new method will be of benefit to the organization of which you are all part of.

How do you introduce new practices in your own organization? Talk to me in the comment section below or on my twitter @jchex



On becoming a software engineer


About a week before this writing, I got an email from my friend. She asked, “How do I get to be good in Python before my interview next week?”

This is not an isolated question, with all the hype the field has been getting over the past years, it has created an illusion within the general populace that it’s easy to become a master engineer.

By consuming media through computers over many years, many have been disillusioned into seeing their familiarity with software products as wisdom into how they work.

Still, just like any other discipline, software engineering can be mastered using time tested techniques.

In this entry, we shall look at what I believe is a viable path towards becoming a master.

Make the big decision to make the smaller decisions

The common misconception is big decisions matter more than small ones. Thus the new year’s resolutions list or the strategic decision making seminar.

In practice, it is the small decisions which are the hardest and the ones that matter the most.

Deciding you want to learn how to code is easy, deciding this Friday evening you will not go out with your friends or watch Netflix but will instead wrangle with design patterns is the hard one.

Find a way to get feedback

The easiest person to lie to is yourself. Have you ever met an individual who first saw an IDE two months ago and today they call themselves senior developers? Well, I have. They are not even lying, they absolutely believe this to be the truth.

The problem this individual faces is they have no idea how they compare to everyone else or what the industry demands of an engineer.

If you can make it through the first arduous days and weeks of programming, it’s very possible for you to be able to hack a semblance of an application. This does not mean you have a programming product.

Brooks explains:

This is a program that can be run,tested, repaired, and extended by anybody. It is usable in many operating environments, for many sets of data. To become a generally usable programming product, a program must be written in a generalized fashion. In particular the range and form of inputs must be generalized as much as the basic algorithm will reasonably allow. Then the program must be thoroughly tested, so that it can be depended upon.

To grow then you must push yourself to work with others, to put your code out there in the world to be scrutinised by others, I assure you, it will make you better.

Build it into your identity

There is no done. The field is so wide, even if you dedicated every single waking hour to consuming the literature available, you would die before you had it all.

Is this discouraging news? I would like to think not, it means your life will never lack purpose. It means every day there is a chance to experience the subtle joy that arises when you learn something new.

Thus you must commit yourself to becoming an engineer, to continuously grow and learn. Becoming better needs to become a natural part of your life just like say eating or breathing. Have you ever met someone who is now a master of breath and now no longer needs to breathe?

Where are you on your path to mastery? Talk to me in the comment section below or on my twitter @jchex


What to consider when growing a software team

A few weeks ago, we had the chance to do Myers-brigs at our office. As it turns out I am an INTJ. You can find your own type on this site human-metrics.

As a base rule, mixing individuals from different personality types leads to better creativity albeit at the expense of efficiency.

Developers, in particular, have an even more nuanced environment. Fred Brooks famously said:

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures....

This means as you grow your team, there are certain things to look out for. In this entry, we will be exploring the factors I think are the most important.

Does the team structure compliment individual’s strengths?

We perform best from a position of strength, yet somehow team leaders assign individuals to tasks optimised for the organisation rather than for the individual’s strength.

A simple test such as the MBTI can help you easily see who would work best with who.

As Wegner proposed in 1985 the greater intelligence born of the group mind which comes about from great collaboration is guaranteed to benefit your organisation.

Is anyone multitasking?

Human’s can not multitask. The illusion feels so powerful that the team leads don’t even need to push this agenda, the developers will take it upon themselves to do it!

Despite numerous studies, including this one Who Multi-Tasks and Why? Multi-Tasking Ability, Perceived Multi-Tasking Ability, Impulsivity, and Sensation Seeking we still assign developers to multiple projects.

Two projects are optimal for an individual developer, in this way, they can switch to a different task to give their mind a break and some room to chew on the project. Anything more is likely to lead to reduced productivity as the mind becomes too clouded.

Have you limited the team size?

We have limited cognitive ability in terms of the number of individuals we can maintain in our circle. Known as Dunbar’s number, it is shown we can actively keep at most 150 active social contacts.

I believe working groups are even smaller. Once the team size gets to more than 5, communication issues start sipping in. It becomes that much harder for the team to build and maintain a shared mental model.

Mike Cohn has an even simpler rule, no team should be so big it can’t be adequately fed by two pizzas!

What is the team’s purpose?

Shortly after joining Moringa, I was having problems getting the team to work together let alone towards any goal. I explained my dilemma to the CEO. She asked me, “Have you carried out a values exercise?”.

This question changed how I think about teams, yes we can impose what we want to the team, but the team just like any other complex system will work towards its own goals.

The only way to get your team to succeed is to imbue them with a sense of purpose which aligns with the organisation.

Can the team deliver the product from end to end?

A basic tenet of the scrum and agile methodologies, in general, is the concept of the cross functional team. The simplest definition I could find of such a team was:

A cross-functional team is a group of people with different functional expertise working toward a common goal.

Cross functional teams are the killer feature of agile. They bring about diverse views to the teams enabling good ideas to be quickly tested, built and shipped.

How long do the teams stay together?

In a previous entry, Stop killing your teams now! we discussed the tragic fate of most teams.

I believe now as I believe then, teams should be built for the long term. Like the tired cliche of the good wine, good teams get better as they mature.

How do you grow teams in your own organisation?


Core technical practises for your scrum team


Scrum is a fast moving development style. There is obviously a lot of advantage to this, but just like a sports car needs a better technical design to function at top notch, so does your code.

In this entry, we will be looking at the top three technical practices that you must adopt to ensure you are moving as fast as you could be.

Test driven development

A few days ago, our team was faced with the challenge of stress testing one of our applications. One particular use case proved particularly hard to do, the only way to run it was to literally have an actual human run through the steps!

This might be fair if we were doing UX testing, but in this case, it proved to be a big red warning sign on our architecture.

We have since worked to correct our process, but the point here is TDD helps you unravel problems before they become Problems.

By writing the test first then the code, you are forced to think through what it is you actually want to do. This makes your code clearer as well.

Not to mention, by having a “second opinion” on the validity of your code, you can deploy far faster knowing another system is checking the integrity of the entire product.

Continuous improvement

If you have ever struggled with your weight, I am certain this thought has ever come up in your mind at one point or another

Let me just eat this burger, I will work it all out later in the gym

A fantastically bad idea! Not because you will procrastinate later and not visit the gym, thou this is likely, but because you essentially threw a good chance of working towards your goal and worse compromised your future self.

In the same way, almost every day you jump into your code, you will come across an opportunity for improvement perhaps a better design pattern to adopt or even just to maximise on an opportunity to reuse code. Here you have the choice of either saying you will just do a patch now and fix it in the future or just fixing it now.

The formal term for it is refactoring and there is a wealth of knowledge out there on how to do it.

By continuously improving your code, not only will your code not rot but you will have code that gets better with age.

Collective ownership

Open source software tends to be of a much higher quality than propriety code.

We all care more about what we know someone else will look at than what we are sure only our eyes will see.

The long and short of it is you want as many eyeballs on your code as possible. Obviously open sourcing your code may not be the ideal solution, but what about having your team members work on the code together?

There shouldn’t be a part fully designated to only one developer, this gives you two key advantages:

  1. Not everything goes to hell if the developer goes on holiday
  2. Everyone cleans up their code just a bit better

Continuous delivery

In 2001, Paul Graham wrote one of the most prescient essays I have ever come across, it is titled The Other Road Ahead.

One of his key arguments revolves around the fact that faster code-test-deploy cycles lead to higher quality code.

I fully agree with this argument. Continuous delivery is guaranteed to significantly reduce if not eliminate the stress which comes naturally with software development.

No longer will demo day be a day of panic. For all intents and purposes, it will just be another day in the life of the boss developer.

I hope these pointers will help you towards a better scrum experience.

Which practices here do you use in your own practice?


What are the different types of requirements and why does it matter?


A software product is usually built with a purpose in mind. There is a reason a good number of web application domains end with “.io “. It literally means Input Output.

Your product takes in some raw information and returns more valuable processed information.

As usual, the devil is the details. What does raw information mean? What does output mean?

Scrum typically adopts user stories as its template for expressing its requirements.

This simple structure of:

    As a __
    I want to___
    So that __

Elegantly captures what the software should do and why.

Still, as the product gets bigger and the requirements pile on, I find it useful to impose some categories on the backlog.

In this entry, we will be looking at some categories which I have found to be useful.

User requirements

At iHub, we pride ourselves in our Human Centered Approach. The simple reason is it works.

The software serves people. At the end of the databases, activity streams, object storage etc is a person trying to get something done. Your success is measured by how successful this person is.

It then helps to acknowledge user requirements as a category on its own.

A typical requirement would be

    As a *researcher* I want to *have my results sorted by relevance* so that *I can get my work done faster*

Business requirements

We talk about the wonders of technology, from the aeroplane to the mini computer in our pockets. Yet, I would argue the biggest invention by humans was the enterprise.

Businesses, are the engines of our society, working behind the scenes, they provide us with all our material needs.

No matter how good, the software or how well it serves the users, if the business does not provide value to its owner then it’s as good as dead.

With this in mind, you must seek to also clarify why it is the client wants the software product built in the first place.

This is usually captured in the client’s vision statement. Of this, the software serves only a part of it.

An example of vision statement from Amnesty International

A world in which every person enjoys all of the human rights enshrined in the Universal Declaration of Human Rights and other international human rights instruments. 

If you happen to be contracted by Amnesty International, you need to remember to imbue this inspiring vision in every line of code you ship.

Non-functional requirements

Robert Gardy in his 1992 book Practical Software Metrics for Project Management and Process Improvement

Came up with the acronym FURPS+

This represents:

  • Functionality
  • Usability
  • Reliability
  • Performance
  • Supportability

The “+” in FURPS+ also helps us to remember concerns such as:

  • Design requirements
  • Implementation requirements
  • Interface requirements
  • Physical requirements

The idea is in addition to doing what it does, software is also required to do it well.

How effective do you think Google would be if it took 5 minutes to give you a response to your query?

I believe by categorising your backlogs in this way, you will able to get more ideas on what is to be included in the final product as well as appropriately prioritise the various backlogs resulting from it.

How do you categorise backlogs in your own organisation? How did you handle it? Talk to me in the comment section below or on my twitter @jchex


Where do unrealistic schedules come from?


This situation is so common, it is by now something of an industry standard. There is almost no project that I have stepped into that had an appropriate amount of time scheduled for it.

You have to wonder why after all these years we still suck at allocating enough resources to get the project done in time.

In this entry, we will be looking at some of the common factors that lead to unrealistic schedules.

External deadlines

Development happens in a context. Unless it is a hobby project, you can be sure that whatever you are working on, someone else is depending on your work output for them to do their job.

A special case would be where the bid specifies the timeline in which the product must be built. In this case, submitting a longer timeline, even if justifiable may mean losing the project.

Since the project is still of interest to the team, the team takes it on knowing full well how tight the deadline is in the process displaying a mix of childish optimism and wishful thinking.

Best case estimates

Murphy warned us:

    Whatever can go wrong, will go wrong

Scrum and other agile techniques give us robust estimation tools. But even with those, we more often than not end up with a range, say 3 – 5 months.

Unless you don’t like promotions, who wants to go to the boss with the higher estimate?

Of course, the problem with the lower estimate is that it holds the implicit assumption that everything will go right.

This is a dangerous assumption, you take it for granted that you have the best tools, language, physical environment, skills etc. When something does eventually go wrong, you find yourself with an unrealistic schedule.

Feeling up to a challenge

For reasons that are beyond me. Some developers prefer working under insane conditions. Something about an all-nighter makes them feel like heroes.

Whether inspired by cut throat work environment or personal bias, teams in these kinds of environments will consistently underestimate how long the project will take.

Even if the pressure is acceptable in the short run, the effect on the team morale and product quality are bound to suffer. Better to have a reasonable schedule and spend any extra time beefing up the quality.

Belief that developers work better under pressure

Authors of the Design Sprint state:

    Times of need can be artificially manufactured by creating deadlines. Our brain doesn’t know the difference. When you create deadlines, your brain stops procrastinating and gives you what you need.

It is easy to extrapolate this kind of thinking to the entire project.

While you do need to pace yourself, you need to be very careful of the kinds of commitments that you make. In a previous entry Estimates, Targets and Commitments. We looked at the dangers of confusing the terms.

You don’t want to make a commitment to your client based on the belief that somehow the deadline will boost productivity if you must make such a commitment, let it be internal.

Scope creep

Inevitably, new ideas will come in. Change is a core part of the software development process.

The problem arises when new changes are introduced to the project but nothing is removed from the backlog. As new features are added, eventually the entirety of the work pushed the project to an unrealistic one.

We have looked at this problem in greater detail here Managing scope creep. The TL;DR is any new change is also a chance to renegotiate commitments.

Have you faced unrealistic schedules in your own practice? How did you handle it? Talk to me in the comment section below or on my twitter @jchex


Why you should do estimation in groups

More than any other activity, estimation of size or effort it will take to build a digital product is based on individuals. Even worse, the responsibility tends to rest on the team lead.

In the midst of the flurry of proposal writing, it may feel like a waste of time to bring in the development team to work on the estimates using a practice such as planning poker. Better use a shortcut and just call the most senior developer and have them give you the estimate.

In this entry, we will be looking at why this is a bad idea and why group estimates tend to fair better than individual estimates, no matter how senior the individual doing it.

The elephant in the room

An old Chinese parable explains this concept very well. Here is the story quoted verbatim:

    Once upon a time, there lived six blind men in a village. One day the villagers told them, "Hey, there is an elephant in the village today."
    They had no idea what an elephant is. They decided, "Even though we would not be able to see it, let us go and feel it anyway." All of them went where the elephant was. Everyone of them touched the elephant.
    "Oh, no! it is like a rope," said the second man who touched the tail.
    "Oh, no! it is like a thick branch of a tree," said the third man who touched the trunk of the elephant.
    "It is like a big hand fan" said the fourth man who touched the ear of the elephant.
    "It is like a huge wall," said the fifth man who touched the belly of the elephant.
    "It is like a solid pipe," Said the sixth man who touched the tusk of the elephant.
    They began to argue about the elephant and everyone of them insisted that he was right. It looked like they were getting agitated. A wise man was passing by and he saw this. He stopped and asked them, "What is the matter?" They said, "We cannot agree to what the elephant is like." Each one of them told what he thought the elephant was like. The wise man calmly explained to them, "All of you are right. The reason every one of you is telling it differently because each one of you touched the different part of the elephant. So, actually the elephant has all those features what you all said."

    Source: [jainworld](

The idea behind this story is that we all have different viewpoints. Until the software product is complete, it is mostly a jumbled mess. Everyone in the team sees only a small part of what the work would entail.

In short, you need the whole team to see the elephant.

Human folly

As a species, we named ourselves Homo Sapiens literally translates to wise man. We couldn’t have been any more wrong in this assessment.

Human reasoning is terribly flawed. The list of our biases is so long that not even a single volume would be able to contain it all. That is not to say they have not tried, see Predictably Irrational, Misbehaving and many other such titles.

Wikipedia has a list so long that it would fit a couple of articles and that is not considering their definitions.

In short, when an individual does the estimates. They will probably seek reasons why their estimate was right rather than getting to the right estimate.

Thankfully, we also evolved a way to combat our biases, arguments. Constructive arguments around the estimate will help everyone think more carefully about their estimate and thus raise the overall quality of the final estimate.

Deep understanding

In an article Minding matter, the astronomer Adam Frank says something very interesting

    When I was a young physics student I once asked a professor: ‘What’s an electron?’ His answer stunned me. ‘An electron,’ he said, ‘is that to which we attribute the properties of the electron’

He does go on to explain the statement. For the sake of this entry, it suffices to acknowledge that the reality of what the product will be is as much what the developers will make it, as it is what we think is an objective product out there.

If this is the case, then understanding the different viewpoints can help us get a far clearer picture of what the developers intend to build and thus a better estimate of the size and effort required.

The rule of five

I like the quote

    Always remember that you are absolutely unique. Just like everyone else.
    Margaret Mead

It reminds us that at the end of the day, our estimates will likely cluster. This is not folksy wisdom. It is a statistical fact. There is a 93.75% chance that the median of a population is between the smallest and largest values in any random sample of five from that population.

Take this rule in comfort, it means that while there is a great benefit to having a group do the estimates, the group needs not be bigger than just 5 individuals.

Do you do estimation in groups in your own organisation? Talk to me in the comment section below or on my twitter @jchex


Sprint is over, now what?

You have just completed your development sprint, done the demo and the review, what next?

The easy answer is jumping into the next sprint. That is of course until the end of the year when reviews are up and you are asked to specify what you have been doing the whole year.

Showing working products is great, in fact, the agile manifesto clearly states:

Working software over comprehensive documentation

Note that they didn’t say No documentation!.

Even if they did, what seems very clear in your mind right now about how the days were used may not be so clear months from now.

Thus my recommendation is that you write a brief report for yourself. It does not need to be official. You can even just call it skipper’s log.

Below are some suggestions on what to include in the report.

Notable events

Not everything that happens in a sprint will be seen in a demo. Perhaps Rico, your new developer, mastered SQL or your team was acknowledged during all hands and other search achievements.

If you do this consistently enough, you will have your team’s story, one that perhaps you can celebrate at your end of the year party, use to review salaries or make decisions on how and what to invest in the team.

Sprint dates

Of course, the start and end dates of the sprint are obvious, how could they not be? Still, the past has a way of blending into what seems like one long day. In this cases, it helps to know that the Sprint commenced on 5th June and ended 15th June and that within this period there happened to be one public holiday or a team mate’s birthday.

This information may give you insights in future planning sessions, specifically how blocked of days for development play out in practice.

Team velocity

Thankfully, most project management tools aimed at software teams will automatically compute this for you. If yours doesn’t. It may be worth it to do the computation yourself.

Velocity = Total story points done in this sprint
Average Velocity = Total story points complete/Total sprints done

You can then chose to plot this information in a burndown chart.

You may want to consider printing out the burndown chart and hanging it on your team wall if you have one.

Retrospective actionable

Your retrospective will likely come up with good practices for the team to implement in the future. While this information is already captured in the retrospective document, I consider this information so important that a little bit of redundancy is allowed. In short, have it in your skipper’s log as well.

This will allow you to quickly reflect on what you thought at the time was important to improve on and thus see how things have evolved since then.

Sprint summary

This would be a subjective account of how the sprint was. With all the talk about objectivity in our industry, telling you to record your subjective experience sounds rather counter productive.

Still, I have found that AHA moments can come from reflecting on your state of mind in action.

What do you, as an individual do at the end of the sprint? Talk to me in the comment section below or on my twitter @jchex