In this series, we’re taking a look at how we do things, and why. More importantly, why we are supposed to do things, and what’s the expected outcome. If you don’t get those outcomes, maybe you should try doing something else, or re-calibrate your expectations.
Now, I know that based on the title, you’re expecting some #NoEstimates stuff, but not today. You can find the #NoEstimates posts here.
Last time, we started talking about iteration planning, and specifically, why we plan for the length of an iteration. Let’s continue with how we plan the content of the iteration and talk about story points, relative estimation planning poker.
Usually we start the planning ceremony at this point:
- The product owner has some stories prioritized by importance. (That’s the result of the grooming process, we’ll talk about that in the future).
- Stories are written to be presented and reviewed.
- While scrum assumes no previous knowledge by the team about the stories, that usually isn’t the case. At least some of the team members have already got some knowledge about what’s needed to be built and tested. These discussions may have already impacted the stories and their prioritization.
- The planning session’s expected result is a list of stories that the team “commits” (ugh!) to complete within the iteration, in order to demo them to the stakeholders at the end.
What happens next?
Let’s start with the purpose. Remember the promise of the iteration plan? Predictability in the short term, that builds trust between the team and the business. Our agreed plan is the basis.
The trust is built when the “commitment” is fulfilled. But at the beginning of the iteration, all we have is the story list. How do we approve a plan?
We need, in a limited time to answer if stories can be completed within the iteration. Our plan is based on the following assumptions:
- “Done” is understood by everyone, in the same way.
- We know how to build this.
- There’s going to be waste.
- There’s going to be change.
Part of the planning we do is capacity planning. We remove all known team availability activities that do not support the stories. (Just realized this requires a post of its own).
While we can take off capacity for the latter two (Jim will be out for a couple of days, Joan needs is going to be swimming in legacy goo so we need to raise it a bit), the two former points aren’t that easy. Even if “Done” is explained thoroughly, it may not be what you get (which is ok), and how we build it changes, when we learn how to build it (which is ok too).
But let’s say we accounted for everything that can go wrong, meaning we know how much actual work we can fit into the iteration. We still need to answer which stories we can fit. Now we’re getting to estimation techniques.
What’s your story?
Story points are a mechanism to abstract real time estimations by using a made up unit. It was conceived for work in a low trust environment, where the business always asked “how long will it take?” and the team said “as long as it takes”. The abstraction would dissolve the discussion (at least that was the hope). You can read about how well it went here. Suffice it to say, Ron Jeffries said “I’m not sure if I was the inventor of story points, but if I am, I’m sorry”.
The Fibonacci numbers usually used for story points, much like t-shirt sizes, are based on the idea that while we suck at accurately estimating something, we can compare two or more items to each other, e.g. “this is at least three times the one we did last sprint”. Fibonacci numbers are spread out the same way, so we can compare stories relatively. It was never the intention to debate if something is a 3 or 5 points. Accuracy is not the point here, and if you’re trying to achieve it, you’re doing it wrong.
Finally, we have planning poker. The idea behind this is not to estimate “better”, but to neutralize dominant opinions, shorten the discussion upon agreement, and open it on disagreement. When putting all the cards together on the table, we eliminate the ol’ “It won’t take more than a three, right?” managerial self-answering question. If you’re quiet, don’t like arguments, and just want to get back to your work – you’ll say it’s a three.
If there are outliers in the vote, some people don’t see the story the same way. It may be about understanding, or complexity, or experience. It requires a discussion. Again, a 3 vs a 5 is not an outlier that requires a big discussion. As a safe measure, go for the 5.
These mechanisms help us come up with a number that represents our understanding of the work. It’s still an estimate. With this numbers, we get a feeling of what we can do within the iteration time limit. It’s not a commitment. It shouldn’t be treated as such.
So when you’re doing the estimation the way you do, make sure it’s helpful for your purpose. Otherwise change it.
By the way, one of the problems with story points or any unit we estimate in, is that we record the estimated numbers, in order to base our future estimations on them. We’ll see why that’s wrong when talking about velocity.
| Reference: | You’re doing it wrong: Iteration planning, part 2 from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
