Estimating the End of Scrum Projects with Fibonacci Numbers and Story Points - dummies

# Estimating the End of Scrum Projects with Fibonacci Numbers and Story Points

Estimating the effort involved in developing product backlog requirements is an ongoing process. The Fibonacci sequence is an excellent sizing technique for relative estimating. With Fibonacci, if something is bigger, you get an idea of how much bigger it is. The last two numbers in the sequence are added together to create the next number. It looks like this:

1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, and so on

As the numbering progresses, the distance between the numbers increases. Use this to acknowledge the lesser degree of accuracy in predicting larger chunks of work.

A story point is the Fibonacci number assigned to an individual requirement (that is, a user story).

Initial, high-level requirements are estimated at the product roadmap level:

• For scrum teams, the development teams understands that requirements with Fibonacci number estimates from 1 through 8 can be brought into a sprint. This level of refinement usually results in a user story.

• Requirements with estimates numbered from 13 through 34 are those that you would let into a release but need to be broken down further before you would let them into a sprint.

• Requirements from 55 through 144 are too big for a release but are estimable at the order‐of‐magnitude product roadmap level. These requirements typically reflect features.

Requirements larger than 144 need to be broken down before the development team can give any semblance of an accurate estimate, so don’t estimate above 144. These may represent broader themes.

Whatever the Fibonacci number, only the highest-priority cards get broken down into sprint-level sizes (which shouldn’t be more than an 8). So if you have a high-priority requirement with a 21 Fibonacci number assigned to it, it needs to be broken into smaller requirements before it can come into a sprint.

With the sizes established, you can apply a few techniques to estimate requirements:

• When you have shorter lists of requirements, begin with estimation poker.

• When you have hundreds of requirements, begin with affinity estimation.

In the estimation process with smaller projects, have the development team sit down with their stack of requirements written out on 3×5 cards. Then ask them to pick a requirement that they can all agree has an effort level of 5. This creates a reference point.

Then have them pick another card, and based on the first one being a 5, ask them what number the next one would be. If it’s greater than a 5, is it an 8? a 13? a 21? This process continues until a few representational sizes have been established. Now you’re ready for estimation poker.

## Estimation poker

A popular way of estimating requirements is through a variation of poker.

You’ll need a deck of estimation poker cards like the one shown. (You can also download the poker estimation app for iPhone and/or Android by searching Platinum Edge Estimation Poker.) You can also make your own deck with index cards and a marker.

Estimation poker cards for estimating the amount of effort required in each requirement.

Because only the development team decides how much it will take to develop a requirement, only the development team plays. The scrum master facilitates and the product owner reads the requirements and provides requirement details, but neither of those two gives estimates. It goes like this:

1. The product owner reads a targeted requirement to the development team.

2. The development team asks any questions and gets any clarifications they need.

3. Each member of the development team picks from his deck a card with his estimate of the difficulty of the requirement.

The estimate is per the complete definition of done, not just to write code. Members don’t show anyone else their cards because you don’t want others being influenced.

4. After everyone has picked a number, simultaneously the team members show their cards.

If everyone has the same estimate, nothing is left to discuss. Assign the requirement that estimate and move on to the next requirement.

If differences exist in estimates, those with the highest and lowest estimates are asked to explain. Further clarification from the product owner is given as needed.

With increased knowledge, everyone picks a new number for that requirement by repeating Steps 3–4.

Normally, you do up to three rounds of estimation poker for each requirement to get the core assumptions on the table and clarified and, at that point, usually have the estimates in a tighter cluster of numbers.

If all developers are in agreement on a single number after three rounds, you’re ready to move on to the next requirement. But you won’t always have all developers in agreement on a single number after three rounds. At this point, go on to a consensus-building technique called fist of five.

## Fist of five

A fast and efficient method of reaching consensus, the fist of five can be used on its own or as an addendum for estimation poker. The purpose of the fist of five is to quickly find a consensus estimate that all team members can at least support.

Fist of five is an efficient way of finding consensus in many situations.

Perhaps some team members have given a requirement a 5, and others have given it an 8.

It begins with the scrum master holding up the requirement card in question and saying, for example, “How comfortable would you be with this as an 8?” Each development team member holds up the number of fingers associated with their level of comfort. If everyone is holding up three, four, or five fingers, it’s settled.

If some developers are still holding up one or two fingers, similar to estimation poker, the outliers would be asked to explain, and further information would be garnered if necessary. The fist of five would be performed again. Continue with this process until all team members can give the number at least a 3 (that is, “I don’t love it but I can support it”).

With the fist of five completed and requirements estimated, you’re ready to move to release or sprint planning.