Estimation

Estimation is difficult for some and therefore a recurring theme. In this article I hope to give you some insights that will enable you to help teams to overcome their impediments for making good estimates.

Why estimation is difficult (according to some).

When new to scrum, teams and scrum masters struggle with the concept of relative estimations versus time. When they get more experienced with scrum,  they get over these growing pains but difficulties with estimating stories often reoccur. Teams can get entangled in estimation details. “Do we estimate bugs and spikes? If we do, these estimates only spoil the velocity and make it useless, because these types of user stories don’t deliver customer value. How about time boxing them? But what does that do to our projected velocity? Oh no, It will go down! Scrum Master, help us, please!” In some cases I have encountered a tenfold of different issue types like documentation tickets, refactoring tickets, questions, dev-improvements,.. you name it. I can’t blame the teams for loosing their grip on estimating that.

If you follow the team down the detail-rabbit-hole, you will get stuck. It makes more sense to take one step back and focusing on solving the real problem. Obviously this would mean reducing the crazy number of different issue types to user stories and bugs only.

Another reason for teams not being able to estimate that I encounter regularly is related to safety. Some teams fear getting “punished” for not finishing all stories they planned. Coaching management is the first priority when you observe this behaviour. I have also seen teams  trying to keep their velocity stable to ensure management satisfaction. I see this happening more in nearshore teams and teams with non-western European cultural backgrounds. Whether these teams do not understand the purpose of estimation or have bad managers is up to you to investigate. You might also want to look in the direction of Agile contracts and cultural training programs for solutions.

Anyway, the end result is that teams are optimizing for getting perfect estimations, which is not a very cool customer centric optimization goal. At least, I have never met a customer who wants to pay for a perfect estimated sprint backlog.

Why estimation is important.

I have tried a zillion of possible approaches for estimation with various teams and with very different results. I encourage you to do the same.

What you want to achieve is a team that “knows” when the sprint is full. The same kind of “fullness” for all different occurrences of sprints (i.e. that takes variations into account like holidays, sickness, bad luck, rain, etc)…, so that the sprint becomes a constant factor on which we can measure the outcome of experiments and delivery of value.

You will help your team if you can get them to fully understand WHY we want to estimate in the first place. When team members get a deeper understanding of estimation, they will automatically get better at it and put their energy into more valuable activities.