How to estimate in scrum?

estimate in scrum
estimate in scrum

How to estimate in scrum each items? What the scrum guide tell us? let’s look together how to answer these questions. For scrum, it’s really important to estimate each item to have a clean product backlog.

What the scrum guide tell us about items?

The backlog items can represent :

  • features
  • functions
  • requirements
  • enhancements
  • fixes

They must have a description, one value, one estimate, an order and the test descriptions to ensure what define that these items will be “done”. These items have to be “done” in one sprint.

Who will estimate the items?

In scrum, all the development team will estimate the items (it’s the recommandation). The Scrum guide don’t explain anything about this topic but remember us every time that the team is responsible together.

It’s not prohibited by scrum that just one person do all the estimates, but if the team choose this kind of way, all the members of this team will be responsible of these estimations. So, if the team delegate the estimates, it keep the responsability of the outcomes.

Usually, the team do the estimates together in the scrum teams.

What are the different ways to estimate in scrum?

How long?

The first way come from the classic method of development like v-model or other waterfall methods : the time. How long to develop this item?

But scrum is not a waterfall method so to answer at this question, you have to takes all skill necessary into account:

  • development
  • UX/UI
  • test
  • design of architecture

So, it’s more complicated to really well estimate each item. Because in the waterfall methods, all the elements are ready just before the development.

Indeed, the risk to do a wrong estimate is higher.

In some teams, the team add every time +30% to prevent of the possible impediments like holidays, day-off, meeting, sickness.

Ideal days

This kind of doing is similar with the first method because the team will estimate with hours or days. But the management of these estimates will be really different.

The team will define “how long to develop this item” without taking into consideration some elements : holidays, day-off, meeting, sickness… And this difference with the last method I have just presented you is importante.

When the team will do the predictibility, it will take the sum of the hours estimated previously of all the element “done” at the end of the sprint into account to define how many items the team could develop in the next sprint.

Story point

This concept is the most popular concept of estimate in scrum. To estimate, the team will take all these concept below into account:

  • the effort to do to develop the request
  • the difficulty (complexity) that may be the demand
  • the risks we imagine to meet during the development of the US
  • any unknowns existing at the time of the estimate
  • potential dependencies with external element

The Fibonacci sequence

Agile teams use this mathematical series because it represents a very important notion: when the item is bigger, it’s more complicated to really estimate it.

The Fibonacci sequence is: 1, 2, 3, 5, 8, 13 … In general, teams stop at 13 but I also see teams include 21.

points d'effort - suite de fibonacci
story points – Fibonacci sequence

Indeed, it’s for this reason, the have 13 just after 8 (and not 9). It’s utopian to think that we can choose between 11, 12 or 13 when the item is very big to develop.

For the predictibility, the teams usually use the same method I described for the ideal days.

Useful link: How to integrate story points in a team?

Be the first to comment

Leave a Reply

Your email address will not be published.