Agile Mentors Community Gets Real about Story Points and Fibonacci
Agilists around the world have been using the modified Fibonacci sequence to remove the painstakingly slow precision out of estimating. Just to review, here is what the sequence looks like for estimating user stories in story points:
1, 2, 3, 5, 8, 13, 20, 40, 100
For the math geeks out there, you probably already noticed the pattern (1+1 = 2; 1+2 = 3; 3+5 = 8). However, when we get to 21 we round to 20. That is because 21 is way too precise and there really isn't a big difference between 20 and 21, so we just call it 20.
If the team chooses to use the story points estimating technique, these numbers become part of relative sizing.
Relative sizing is a simple way to compare two items. If we call something a 2 we are saying that there is twice as much effort, complexity and uncertainty than if we call it a 1.
Estimation Patterns & Practices
The agile community mentors recently had a discussion about whether they always stick to this modified Fibonacci series or whether teams tend to develop their own patterns and practices as they mature.
They asked, Is there a common estimation pattern if mature teams are given a single, well-written user story?
The community also debated whether the higher numbers are used with any regularity:
Are the numbers 20 and above worth using anymore or are they just there to give notice that a story is too large?
An AMC member observed that with most of the teams he works with, when a story receives an estimate of 13 or greater, it typically prompts those teams to initiate a splitting discussion.
A team in Minnesota says they only estimate with 1, 3, 5, 8, 13 and possibly 20. All other cards in the deck are thrown out. For them, estimates of 8 points and higher initiate splitting discussions. The team continuously uses the INVEST model for estimating: independent, negotiable, valuable, estimable, small, testable. However, if they are looking at a large feature, they will use the higher numbers. (For more on why large numbers can be valuable, you might want to read "In Defense of Large Numbers.")
A member from Michigan recently took the MGS Better User Stories video course and learned a great tip:if a story is greater than ⅓ to ½ of the team’s velocity, it's a good idea to try to split it.
A member from New Zealand agreed that double digit numbers start to lose usefulness for relative estimating. He pointed out that the modified Fibonacci sequence gives teams a plus or minus 30 percent variance, which stops teams from getting too hung up on, “Is it a 3 or is it a 5?”
Most members agreed that the important thing with estimating is not precisely which numbers you use, but that teams use the same consistent scale. Estimates shouldn’t be compared across teams, but as a team works together consistently, they should develop a rhythm for estimating and a shared understanding of the process.
According to a recent speaker at the Minneapolis Global Scrum Gathering, stories further down in the product backlog can be “lumpy,” which is in line with the Mike Cohn’s metaphor of the product estimation iceberg, where stories near the surface should be much smaller and more detailed than those that will come later in the project. You want to save the work of breaking down these tasks until closer to when they’re going to be worked on so that you have more information on the system and you know with greater certainty that the work is going to be needed.
A community member said that “the real magic happens” in Part II of sprint planning, where the team decomposes work into tasks and estimates using time. His team prefers to estimate tasks into ¼ day increments and bases this on a six hour day, allowing time for breaks and meetings. They don’t estimate tasks for any longer than a day to keep the team accountable for completion of work on a daily basis.
Estimates & Team Velocity
During their discussions, the community cautioned against estimate inflation. When you witness teams with really large estimates, it may be due to management asking them for a higher velocity number (the sum of story points completed each sprint). This gaming happens when a team is being compared to other teams or incentivized for a high velocity number.
Mike Cohn’s experience emphasizes the fallacy of focusing too much on how high or low a team’s velocity number is. Mike has worked with hundreds of teams and no matter the sprint length, the average team’s velocity is somewhere between 20 and 50. However, one of the best teams he has ever worked with had a velocity of merely 11. This demonstrates that velocity is not the best indicator of how good a team is, because team estimates can vary so much.
There are many different perspectives out there around estimating. While Scrum is a framework for agile, it doesn’t prescribe any specific way to estimate. However, many agilists find that using techniques such as the modified Fibonacci sequence and story points are valuable techniques for improving agility.
To read the entire discussion and many more, consider joining the Agile Mentors Community by visiting www.agilementors.com.