Transition to Story Points with Fibonacci sequence
Story Point is a popular measuring unit used by Agile practitioner. It is not limited to Scrum only, but as Scrum is the most popular Agile framework, it is often mentioned together with Scrum (so will this article).
Story Point unit is defined by the scrum team; every scrum team defines its own Story Point unit. It is called Story Point, since user stories are estimated, but it could also be “Apple”, “Banana” and so on instead of “Story”. In early days, “Gummy bears” and “NUTs” (Nebulous Units of Time) units have been used in Agile Frameworks instead of time estimation.
The Scrum Guide, does not refer to any estimation techniques or units. It is mentioning that Product Backlog items should be estimated and that the development team is responsible for all estimates.
Why replacing time estimates
According to Ron Jeffries, one of the founders of Agile framework Extreme Programming, the reason for replacing time to other units have been due to following reason:
There are a number of ideas about how to estimate using something other than time. Points, Gummi Bears, Fibonacci numbers, T-shirt sizes. These were originally invented to obscure the time aspect, so that management wouldn’t be tempted to misuse the estimates. (I know: I was there when they were invented. I may actually have invented Points. If I did, I’m sorry now.)
Story Points by itself have no value to business but are needed for calculate metrics such as Velocity, Work Capacity and Focus Factor. The initial reason for replacing time estimation might be due to obscure the time aspects and make the Scrum team less worry about estimates, but as mentioned by Scott Downey (founder of Rapid Scrum) and Jeff Sutherland (co-founder of Scrum and co-writer of The Scrum Guide), metrics give an insight to the team’s performance to the team itself and help the Scrum Master to plan the upcoming Sprint. Metrics are also important to see the impact of any modification, team changes, and new tools and technologies.
Relative values
It is difficult for people to measure something directly. People are bad at estimating and predicting but are good at comparing. Researches show that hourly estimates have very high error rates. But by comparing, relative values are created. Story Points are relative values.
Imagine two people that should walk to a house far away. One walks slow and the other one walks fast. If you ask them “When will you reach the house” one will say, after 20 minutes and the other one after 40 minutes. Depending on their speed, they will answer differently and they will not agree on a common time. But both of them can be convinced that the house will be reached after 10 km. 10 km is then an absolute unit. Lets transform 10 km to 1 Story Point unit. Show them another house. Relative to the first house, the second house is twice as far away. Now, it will be easier to agree on a common unit. The second house is twice as much far away than the first house, so 2 Story Point unit will be agreed on.
Parameters that affects the estimate
Founder of Scrum Alliance and author of “Agile estimating and planning”, Mike Cohn, has covered a lot of Agile estimating and planning process on his website Mountain goat software. His book was published year 2005, so the blog on the website might be more up to date than the book. The examples in this article have been gained from his website.
Mike Cohn mentions in this blogpost, that Story Points should include everything involved in the development phase that could affect the effort to develop the Product Backlog item. It should include the whole process of the team’s Definition of Done (DoD). For example, if the DoD includes test automation, then this should also be included in the estimation.
The amount of work, complexity, and risk and uncertainty are parameters that affect the effort and that should be taken into account while estimating. The effort can be calculated with following formula:
Effort = Amount of work + Complexity + Risk and Uncertainty
Let’s take a closer look at these parameters.
- The amount of work. The amount of work to do.
Example: Imagine a webpage with one input field and another with many input fields.
- Complexity. The complexity of the story.
Example: Imagine a webpage with 10 plain text fields and another web page with 10 fields but with Calendar field, validations, pre-formatted fields, interaction between fields etc.
- Risk and Uncertainty. Risk is a predictable outcome that should be reflected to the estimate. Example of a risk; change in some old code that doesn’t have automated test. Uncertainty is an unpredictable outcome that should be reflected to the estimate. Example of uncertainty; an unclear Product Backlog (PB) item. Both risk and uncertainty will affect the estimation.
Transition to relative units
Following steps can be good to have in mind while getting started with and implementing relative units.
- Choose estimation unit. There are different estimation units. Begin by choosing an estimation unit. Story Points might be a good start.
- Choose number sequence. Fibonacci sequence is used a lot while estimating with Story Points. Too big user stories are not recommended. Fibonacci sequence up to 13 as maximum is enough and most of the Planning Poker cards are up to 13. Too big user stories can be broken into smaller user stories.
Zero-story point exists also and that can be applied to tasks that require almost no effort at all. - Choose reference stories. Do not only choose a one-point story and give estimation relative to that one-point story. Using small user story as reference tends to make the stories to be estimated too small. A good way can be to reference one, three and five-point stories.
- Accurate estimations. Too make estimations more accurate, compare the item being estimated against two previously estimated product backlog items.
Everyone in the team should agree on given estimation. If there are different estimates, then the average should not be used. The highest given estimator and the lowest given estimator should point out their point of view and discuss and the whole team should thereafter agree on a estimation. - Estimation techniques. Planning Poker is a popular gamified technique for estimating. More about planning poker can be found here and here.
Who should participate in estimation
The whole scrum team should participate. The product owner should participate to give details about the PB items, but he/she should not give estimation. As mentioned in The Scrum Guide, only the development team should give estimation. A pure scrum master should estimate only by invitation of the rest of the team. A scrum master with a technical background can estimate along with the development team.
To sum up: Story Points are relative values that rate the relative effort of work. Story Points can be used to calculate metrics such as Velocity and Work Capacity and by that give an insight to team’s capacity and performance.
It might take a while to get used to relative units when giving estimates, but the important thing is to make sure the whole team is at the same level on what a Story Point is and by that estimate more accurate.
