If we size our stories along the Fibonacci scale (1, 2, 3, 5, 8, 13) should we expect that we could complete approximately four 2-point stories in the same time as an 8-point? or thirteen 1-point stories in the same time as a 13-point story?
Add a comment
|
4 Answers
Story points are designed to compare baskets of varying sized stories
...should we expect that we could approximately four 2-point stories completed in the same time as an 8-point? or thirteen 1-point stories in the same time as a 13-point story etc?
Yes, but don't stretch it to the extremes.
Use that equivalence at the sprint velocity level. That is what is the very purpose of story points. You are trying to make a rough assessment of how much you can schedule into each sprint with a reasonable chance of completion.
However, two cautions:
But that does not mean you should say something like, “One story point = eight hours.” Two developers can start by estimating a given user story as one point even though their skill level may be very different.
Don't use story points for Sprint Planning. During sprint planning break-up product backlog items into tasks and estimate each in hours. This will give you a better handle on how much the team can committ.
answered Apr 22, 2015 at 17:42
This is a very confusing topic about story points. The purpose of story points to to have a rough understanding of relative size of stories. To get an idea of how this works, try replacing the numerical values with t-shirt sizes. You could still break stories into small, medium, large, xl, and so on to understand how big one is relative to another, but no amount of small t-shirts result in a large t-shirt.
It's also important to understand that we use story size estimates to describe effort, not time. This can also be confusing because there is often a correlation between the two, but it's not solid, so you can fall into a pretty big trap if you assume the two are directly linked. Mike Cohn has an interesting blog post about this that compares it to running. The effort is the distance run and if I run a 5k in 25 minutes, next week it'll probably still take me around 25 minutes, but I can't assume that a 10k will take me 50 minutes or that the same 5k will take someone else the same 25 minutes.
I think your safest bet is to not apply math principles (2*4=8) to story points. If you see patterns emerge over time, it's usually safe to leverage them, as long as you know that they aren't solid.
I believe story points overcomplicate the planning process. They are an unnecessary abstraction. IMHO; if you can, stick with hours
In general, I use both story points and hours. I also work hard to decouple any kind of comparison between the two. They are two different measures which give two different views into the level of commitment as well as health of the sprint when in progress. (Note: I'm assuming scrum here.) To this end, I move away from using any kind of points-to-hours conversion/comparison chart as soon as possible. Although it is helpful to sometimes start with just such a chart.
Time estimates are familiar to delivery team members and are somewhat easy to quantify - everyone makes estimates for how long something is going to take in many aspects of their lives, not just work assignments. If used in concert with evidence based scheduling, the release cycle can reveal valuable insight into the estimation skills of the team and individuals.
I frame story points as a measure of all the other "stuff" about estimating a work effort: complexity, card dependencies, client dependencies, technical challenge, problem definition, etc. - basically, that immeasurable intuitive feel a team member has based on experience in the industry, with the company, and with the team.
With respect to the Fibonacci scale, I've found it much more useful to have 3-5 points reflect something around an 8-hour-ish effort. When efforts start showing 8, 13, and 21 points, it becomes much more apparent to the individual and the team that a story may need to be broken into smaller tasks. That's the value using something like the Fibonacci scale. It helps shake out planning fallacy bias if used properly.
