This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Keene the Product Owner addressed the Scrum Team. “Some left-handed users are complaining they can’t easily adjust the flux capacitor torsion. I don’t care whether we call this a bug or a feature, but I’m hoping to address it within the next few Sprints.”
Kelsey, the team’s ScrumMaster, recalled “We have a Product Backlog Item in the Product Backlog for that. Shall we estimate it now?” And why not? It was a couple days before the next Sprint Planning Meeting. The entire team was present, and had their estimation cards handy.
This item happened to be in User Story form. “Left Handed Torsion Controller: As a left-handed time traveler, I want easy access to the flux capacitor torsion controller so that I can travel in time without getting a repetitive stress injury.”
Each team member (but not the Product Owner) held a set of estimation cards. These particular cards had T-Shirt sizes on them: XS, S, M, L, XL, and XXXXL, along with corresponding logarithmic numbers (1, 2, 4, etc.). It took each team member less than a minute to pick a card, knowing this was just the first of several rounds.
Team member Enrique picked his “S” card. To avoid biasing the team (an “anchoring effect”), he waited until everyone else had picked their cards before showing his. “I called this a ‘small’ because it’s just a mirror image of the right-handed torsion controller we already built. Really, it’s easy, especially if we use the JLefty third-party module.”
Team members Zorro and Calvin weren’t so optimistic. They held up “M” cards, for “medium.”
The team member who tended to think about QA the most, Fantasia, showed her “L” card. “This story is large! Remember last time we added the lambswool thumbwheel to the torsion controller? Our regression tests showed the power converter overheated when the undercarriage strobes were in police car mode. We worked our butts off replacing neon fixtures with LEDs, then creating new luminescence tests because our definition of ‘done’ includes end to end testing. We still need to pay off some technical debt with the power converter that hack Miguel designed in 2003.”
The team members nodded, remembering the mad dash to buy radiation-hardened thermocouples from Fly’s Electronics before closing time, only to discover they no longer carried metric parts.
They had been talking for about two minutes when Kelsey suggested, “Revote?”
The second time around, most team members held up “L” cards.
But now Lucio, the team’s ergonomics expert, was holding up his “XXXXL” card. He scratched his mustache. “I changed my vote because I realized this is actually an epic, a story containing other stories. Full support for left-handed users would also entail moving the LP turntable speed knob to the other side of the cyclic pitch controller. Also, I’m not in favor of doing yet another piece in lambswool when our user feedback indicates they relate better to our new gatorskin theme. We don’t want this thing looking like a mantis.”
Product Owner Keene stepped in, saying “Let’s add new stories to the backlog for those requirements so I can prioritize them independently. Nearly all our users leave the turntable in the default 33 RPM mode. I’m considering dropping support for 45 and 78 RPM altogether. Stakeholders Vito and Lothario want the torsion controller fixed in time for the left-handed time traveler’s convention. It’s very, very important to the business. I agree about the gatorskin thing, so let’s add that to the acceptance criteria for this story.”
Kelsey: “Let’s vote a third time. Consider whether the use of gatorskin will affect your effort estimate.”
And so it went….
Usually the team will converge on one estimate within three rounds. If they got close enough by the third round, Kelsey would have averaged them and moved on to the next item.
Some guidelines for the estimation game:
- The Product Owner needs effort estimates for Product Backlog Items in order to prioritize them appropriately (and later, to measure velocity for release planning). Getting the estimates done a couple days before the Sprint Planning Meeting gives him/her time to prioritize them.
- While the Product Owner can estimate the business value, only the development team can estimate the development effort. And it has to be the whole team, because they’re all collectively responsible for getting it done. Team members consider the effort for all parts of the story, such as analysis, design, coding, testing, and refactoring. All items contain a degree of risk; team members consider that in their estimate and boil it all down to one estimate.
- The estimates are relative to each other, not absolute time units. Establishing the initial baseline for what your team considers a “medium” takes a little time. You might start by saying an M is about one day of work for a team member (remembering that Scrum teams are meant to collaborate), and an XL is about three days of work for three team members. Anything bigger than that is an epic.
- It’s fine to leave an epic in the product backlog, but it should be broken down into its constituent stories (in thin vertical/visible slices, not by tasks) before committing to a Sprint.
- Team members pick their estimate before revealing it. This is done to get a better cross section of opinion from the whole team, countering the tendency to be unduly biased by the first team member to speak out.
- The first time around they probably won’t match. Spend only a couple minutes discussing it, and revote. The outliers in particular should discuss the rationale for their estimates.
- If the estimates match, record the corresponding number (for instance, using the Danube cards an “M” would be 4 effort points) and move on to the next item.
- If after three times around, the estimates almost match, just take an average. The point of this game is to end analysis paralysis.
- What if the estimates aren’t converging after three tries? The team should not commit to a blank check. Further information is needed. Take on a small investigate item to produce a concrete estimated development story in the product backlog for a future sprint.
- It gets easier each time you do it.
This game is also called “planning poker” — an apt name because every estimate in product development is a gamble. We use a rough, relative scale to make the uncertainty explicit. Do not confuse this with XP’s “Planning Game,” which is analogous to the Sprint Planning Meeting. Estimation does not have commitment. Commitment occurs in the planning meeting.
Any questions? Post them here.
Our initial hand-made estimation cards worked so well as a teaching tool that we’ve had some professionally designed and manufactured. We’re giving these away to our CSM participants. Contact us if you need more.
Download the PDF version: Estimation Game blog