As an agile coach, it seems one of the areas that teams struggle with the most is in estimation. And by estimation I’m implying some of the following:
- When do you “task out” the story? Who provides estimates for the tasks? And in what units?
- How do you breakdown, estimate, and re-estimate user stories? When are you “done” estimating them?
- Story points are relative and high level – should we convert them to hours or time?
- At scale, let’s say 10-20 teams, the estimates are interconnected across some teams. How do we handle dependencies and integration?
Mishkin Berteig has published a nice overview of 9 estimation techniques. As part of this article, I will review each one from my own perspective. Some I’ve used and others I’ve not. I’ll share my own stories to compliment the techniques.
http://www.agileadvice.com/2015/10/13/agilemanagement/9-agile-estimation-techniques/
But beyond that, I want to provide some simply guidance for estimation approaches that I’ve found to work over and over again within many teams. I’d recommend you read Mishkin’s post before going any further…
Planning Poker
This has been a go to technique for me in agile contexts for over 10 years. I often vary the units (T-shirts, Team Sprints, Fibonacci, etc.) depending on the “level” of estimation we’re doing.
When I say level, I’m also talking about the speed / number of estimates you’re trying to achieve.
The “roots” of Planning Poker is Wideband Delphi and the emphasis is on sharing the WHY behind your estimates rather than debating estimates.
The Bucket System
I’ve really not used it. It sounds like a much larger scale variant of Affinity Mapping, which is discussed later.
Big/Uncertain/Small
Again, I’ve not used this technique. Both The Bucket System and this one use divide & conquer as the primary estimating technique. That is, a “baseline understanding” is established, and then team members break up and break things down individually or in smaller groups. I’m not sure I like the techniques because of this. I typically recommend whole-team approaches to estimation.
However, I can see these being effective when you have LOTS of stories or PBI’s very early on in a project that you have to get a high-level feel for.
TFB / NFC / 1 (Sprint)
I’ll refrain from commenting much on this one. However, I have used a similar, sprint level approach for early estimation of epics and features.
I’ll ask the team to estimate in # of sprints for the entire or sub-team. For example, this epic would engage ½ the team for 3 sprints. Not only is this surfacing a rough estimate of size, but it’s also teasing out skills sets, and efficiency from the perspective of swarming around the story.
It also helps the team “think more like a team” when doing their estimates.
Dot Voting
I was frankly surprised when I saw Mishkin bring this technique up with respect to estimation, as I’ve nearly always used it for prioritization. As he says, it probably only works well on a small group of stories.
I also wonder if and how you drive discussion “around” the dots?
T-Shirt Sizing
I often blend T-shirt sizing into the units used for Planning Poker. Simplifying them from Fibonacci.
Here Mishkin is alluding to them being their own technique that is more of team doing simple groupings, with conversations. I can see that being quite effective as well.
The one thing to keep in mind, and this is my experience, is that the smaller the number of choices you have in your estimation units, the more focused and effective the estimation discussions are.
Affinity Mapping
To be honest, I wish I used Affinity Mapping more in my coaching practice. I think it’s a great way to “process” a pile of stories.
The technique focused on grouping similar stories (in size, in complexity, in scope) together. Think in terms of creating “piles”.
Once you have the groupings formed, the team agrees on estimates for each pile; so collaborative in the grouping and in the final sizing.
Ordering Protocol
This is another technique that I’ve never used. But the dynamics intrigue me – particularly the conversations that might emerge as the entire team engages in the ordering.
Divide until Maximum Size or Less
Again, I’ve not used this approach. I have seen teams that have “goals” for their estimation. For example, they want to break stories down to 5 points or less as part of their Ready-ness Criteria.
That sort of guideline can be effective for consistency in estimation and in execution results (velocity stability).
Common Estimation Patterns to Try
- Estimate at different levels (Epics vs. Stories) so that your keep your perspectives flexible and don’t fall into a trap of boredom or by-rote estimation.
- Remember that Epic-level estimation is typically FOR the Product Owner for forecasting and roadmap planning. Then Story-level estimation is FOR the team. Sure there is a connection between the two, but often the units, goals, and level of discussion are quite different.
- Please remember that the key to agile estimation effectiveness is not related to the estimates themselves. It surrounds the conversations that the estimation inspires.
- Iterate on your stories, which is why I don’t prefer some of the single-shot estimation approaches. And allow for some time between estimation “discussions”.
- In any relative estimation scheme, consider: level of effort, complexity, and risk when estimating.
- Don’t tie estimates to individuals and remember that estimates should represent ALL WORK required to get the story DONE.
- I’ve already said this, but it’s worth repeating, the simpler the units the better the conversations.
- Realize that stories ultimately need to fit into a sprint. So don’t overly decompose them, just for a false sense of security.
- Mishkin made a point in his description of Planning Poker that the estimates need to converge to a single, agreed value. I actually don’t see it that way. I look for narrowing, but not global agreement on the estimate. I do look for the team to agree on what their estimate outcome will be. Often they agree on the higher of the estimates in the range. So, try to converge, but don’t get stuck on unanimous agreement!
Personas & Reference Stories
In this blog post, I explore the notion of reference stories and personas. I’ve found that developing both can truly help your estimation.
The basic premise is that you have examples to help you envision your stories and the subsequent estimates.
Wrapping Up
I want to thank Mishkin again for his post. Estimation is one of those topics that most agile teams struggle with. I think having options is a great way to attack the estimation challenge.
I’d like to hear from readers about your learning’s and insights around agile estimation. I’d like to hear less about techniques and more about practices or patterns that work for you.
And here’s an interesting post on relative estimation - https://www.linkedin.com/pulse/20141103162528-25825330-estimating-dog-sizes-is-easy-estimating-software-is-not-fast-agile-skills
Stay agile my friends,
Bob.