Agile Estimation: Approaches

Agile Estimation: Approaches

The software development process, with its constant uncertainties and frequent changes, together with the difficulty in getting users to articulate their requirements, has long been a headache for project managers.

Agile development processes still bring with them some of these headaches, but we can simplify the estimation process. I have listed some of the approaches below.

Planning Poker

Planning Poker is a technique used to estimate the relative size of tasks, or the effort required to complete them, in software development. A development team estimates using a deck of cards that are usually a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, … ) to indicate the difficult of the task. You can easily replicate this by asking the team to make their own cards. When starting off in Agile, sometimes teams equate this to the number of hours required to perform the estimated task – though this is probably not the best way to do it.

Agile Estimation:

The estimates occur as follows:

An item is selected for discussion.

• Each team member chooses a card that most reflects the “size” of the selected story (or task). This decision is based on the knowledge and experience of each member of the team.
• All members show their cards at the same time so that there are no changes of mind after each member has seen the other hands.
  In most cases we will have cards with different values. The divergences, and the reason for the differences in the estimates, is discussed. Large divergence suggests a lack of information, in which case more negotiation/discussion must occur in order to get agreement on the estimation.
• The story estimation ends when the cards’ values converge to a value agreed by shared consensus of the team.
  Agile Estimation using the Fibonacci sequence

Consider the sequence of numbers 1, 2, 3, 5, 8, 13, 21, ….

Each number is the sum of the two previous numbers. In some cases, the numbers are rounded up or down to the nearest 5 or 10. Often a 0 and a 1/2 are also added. 0 (zero) represents a story that requires no appreciable effort to develop; for example, if another story already being completed will be used to end this story.

Generally, the question mark is used to indicate that a team member does not have enough knowledge of the story to estimate it, and thus requires more discussion and greater detail about the story.

The symbol of infinity is used to indicate that a story is too large to estimate, more like an epic, and so needs to be broken down into smaller stories.

The idea here is that the team should really develop their own technique for building out estimates. Time may not be the best measure, as the team should be trying to get more efficient in each subsequent sprint. The non-linear nature of the Fibonacci sequence makes it harder to sit on the fence with in-between estimates.

Estimate user stories using T-shirt sizes

There are several other ways of estimating stories, another of which is T-shirt sizing. In this type of estimation, stories can be small, medium, large, or XL. What exactly these sizes mean depends on the team. In addition to the terminology being familiar and easy to use, even by non-technical people, this works really well on teams with very short iterations.

Conclusion

Estimating software delivery times really is an art. The accuracy of the estimate depends greatly on each team, as well as the level of detail available for the estimate. The most important thing is for each team to evolve, always seeking to increase the accuracy behind the estimates.

In addition, estimates combined with good retrospectives can help identify parts of a s.ystem that need refactoring. For example, if stories fall behind, or are often labelled as difficult, you can investigate what these stories have in common, and seek solutions that can mitigate those problems.

Of course there are many agilest that advocate no estimates at all