Since this article was first published, The Team Estimation Game has evolved into something even better: Easy Estimation With Story Points. If you are looking for a fast and effective way to estimate, we recommend going straight to that article. If want to know where Easy Estimation With Story Points came from, keep reading.
The Team Estimation Game plays like a game, but it accomplishes valuable work: assigning story point estimates to user stories.
Teams using this technique are typically able to estimate 20 to 60 stories in an hour. The game was invented by our friend and colleague, Steve Bockman. Here is how one team plays the game:
Team Estimation Game Part I: The Big Line-up
Frank, the team’s scrum master, has cleared space on a long section of wall in the team room, and now the team assembles in front of it. Brad, the product owner, has brought a stack of 30 user stories from his product backlog, and the team is going to size them by playing the Team Estimation Game.
“Kira, why don’t you go first?” Brad says, passing her the stack of story cards. Frank, who is holding a roll of blue painter’s tape, peels off a small piece and hands it to her.
Kira starts the game by taking the top story from the deck, reading it aloud, and taping it to the middle of the wall. Then she hands the deck off to Kai, who goes next.
Kai picks the next story off the top of the deck and reads it to everyone. “I think this one is bigger than the one Kira just placed,” Kai says, affixing his story to the right of Kira’s story.
Mark goes next. The story he reads strikes him as a small one, so he places it just to the left of the others.
Now Jeff picks a story off the pile. “This one is pretty small, too.” He hesitates, then moves Mark’s small story further to the left to make room for his. “But not as small as the one Mark just placed.”
The team continues to take turns placing stories. On Kira’s third turn, she doesn’t take a new story off the pile. Instead, she repositions one that is already on the wall, moving it further to the right. “Trust, me,” she says, “the legacy code for this one is a mess, and we are going to have to make it all thread-safe for this story to work!”
Soon enough, all of the stories have been placed on the wall—but the team continues to take turns. Now, instead of placing new stories, they are fine-tuning the order by moving them one at a time, sometimes silently, sometimes with a few words of explanation.
“Pass,” Malay says when his next turn comes, indicating that he is satisfied with the order of the stories. Justus passes during this round as well. Kira and Mark each move one more story, but pass on the next round. Eventually there is a round where they all pass. Part one of the Team Estimation Game is over!
The team now has their stories ordered left to right, smallest to largest. The story they all agree will require the least amount of work is farthest to the left, and the one that they believe will require the most amount of work is farthest to the right. What is remarkable is that the whole team has now achieved consensus agreement on the correctness of this ordering!
For those who have been paying close attention, you may have noticed that this game has the potential for an infinite loop. Mark might place a story to right, but then Kira could move it back to the left. Mark, in his next turn could move it to the right again, and so on forever. While the infinite case is theoretically possible, we have never encountered it the hundreds of times we have played the game.
Team Estimation Game Part II: What’s Your Number?
In preparation for round two of the Team Estimation Game, Frank produces a deck of Fibonacci cards. Each card in this deck has one of the Fibonacci numbers on it, from one to 144.
Mick starts off. He goes up to the wall and points to the leftmost story, vamping a bit like Vanna White on Wheel of Fortune. “This, ladies and gentlemen, is about the smallest story we are likely to see.” He tapes the Fibonacci card labeled “1” above the story.
Justus goes next. He holds up the card labeled “2” and considers the wall of stories, searching for the point where the stories on the wall start to be about twice as much work as the story with the “1” over it. He chooses his spot, and places the “2” card above a story that lies four cards in from the left.
Play continues for several rounds, with each team member placing a Fibonacci card above the row of stories where they believe a size break occurs.
When her next turn comes, Kira hesitates, then points to two stories. “You know,” she says. “I think we may want to reverse the order of these two. I think this one is an eight, and the other one is a 13.” She uses her turn to switch the order of the two story cards and hands the deck to Mark.
Mark places the “21” card above a story. Malay is next. He shakes his head, then removes the “21” card Mark just placed. “I think this is actually a 34,” he says, naming the next-highest number in the Fibonacci sequence. He replaces the “21” card with the “34” card.
“He’s right,” says Jeff.
Jeff helps Malay move the story cards just enough to create a blank space between the last size 13 story and the first size 34 story—when the team placed the story cards in round one; they left ample space between them to allow for this, knowing that things can shift during part two.
Malay tapes the “21” card above the blank space in the row of stories, to indicate that there are no stories of that size.
When everyone has reached the point where they feel confident enough in the sizes to pass on their turn, the game is over.
Now the team tidies up, moving the story cards to form columns under the Fibonacci cards. All the stories between the “1” and the “2” are collected in a single column under the “1” card; these are the one-point stories. The next column consists of all the two-point stories, and so on. The team never did put any stories under the “21, ” so that column remains empty.
What we’ve described is the simplest form of the game. When you play it on your team, note that you don’t have to start with a “1” as your smallest story size. If a player thinks there may be future stories that will be significantly smaller than the smallest story that is currently on the wall, they may opt to start with the “2” or “3” above the first story instead of the one. This leaves room for future stories to be sized smaller than the smallest story in the current set. For example, by placing a “2” over the leftmost, smallest story card, a player signals their belief that the team may encounter future stories that are half as much work to implement.
We teach this game to the teams we work with, and many of them tell us that they have never before started a project with the whole team believing that the estimates were correct. This is the way to build a plan that everyone actually believes in!
Excerpted from The Elements of Scrum, by Chris Sims & Hillary Louise Johnson.
©2011 Chris Sims, Hillary Louise Johnson and Agile Learning Labs. All rights reserved.
For Chris’ latest approach to estimation, read Easy Estimation With Story Points.
We played this game this morning. What an efficient way to estimate a large number of stories in one sitting… without losing consistency or perspective.
In the Sprint Planning Meeting , the team sits down to estimate its effort for the stories in the backlog . The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and, as a result, forecast releases based on velocity . This means the Product Owner needs an honest appraisal of how difficult work will be. Thus it is recommended that the Product Owner does not observe the estimation process to avoid pressuring (intentionally or otherwise) a team to reduce its effort estimates and take on more work. Even when the team estimates amongst itself, actions should be taken to reduce influencing how a team estimates. As such, it is recommended that all team members disclose their estimates simultaneously. Because individuals “show their hands” at once, this process is not unlike a game of poker. Unsurprisingly, teams often call estimation “planning poker.” Some teams have even developed their own decks of playing cards expressly for this process.
Actually, it is vital that the product owner be present when the team is estimating. The team needs to be able to ask the product owner questions about the stories, so that they fully understand them when they make their estimates.
Additionally, this estimation should not be taking place in the sprint planning meeting. That’s too late! All of the high-performing scrum teams I work with adopt a weekly storytime meeting (sometimes called a backlog grooming or backlog refinement meeting) where they estimate stories, agree upon acceptance criteria, split large stories into smaller stories, and allow the team to tell the product owner which stories are ‘sprint ready’ and which still need further refinement before the team would be comfortable taking them in to a sprint.
Cheers
Chris
@Hillalry – Thank you for sharing this technique in the instructive way you did!
@Chris – Thank you for sharing your comments. You perspective is my coaching to teams and POs. At my current engagement, we’re in the process of implementing these discovery & refinement sessions to “Ready” work for estimating by the team (so they can get stories ready to estimate with PO before sprint planning, and sized to pull into sprint planning) so that they can do what they really need to do in sprint planning, and that is to discuss HOW the value-prioritized stories to do next will be implemented, and thereby plan to capacity what the team can complete in the next sprint. This is for most part currently being done in a l-o-n-g half-day planning session for a 2-week sprint. We’re going to implement multiple shorter sessions to get work readied upstream so the whole team can see past their nose, and accomklish the sprint planning session itself in a fraction of the time, with greater clarity of target and approach, as well as team awareness and buy-in on estimates and sprint commitment/goal. Upon first experiences, the feedback and results are encouraging. We’ll continue until we’re humming on the benefits of doing so.
Thank you for sharing.
Cheers indeed!
JimBo
Hi Chris,
Where I agree that the team need to refine stories before they come into planning, it is sometime in response to change where, stories have to be estimated during planning. In my personal opinion, by the business being present at estimation will seriously influence the process negatively albeit inadvertently.
As I’m sure you appreciate, depending on the audience and the asker of a question the answer might be swayed, therefore, in order to impress the audience the team might over estimate what they can achieve during a single sprint.
To mitigate the influence, I ensure we have regular refinement sessions (I like ‘storytime’) and where it becomes necessary, I split the planning sessions into 2 part. Sprint planning part 1, The Product Owner sets the vision for the forth coming sprint and present the stories (wish list) the would like Done during the sprint. In this session the team have the opportunity to ask as many questions as is needed to achieve a common understanding of the requirements before this wish list is taken into part 2 which will be where the real team work is done.. story estimation, creating a sprint backlog, sub-tasking (where applicable), capacity planning and agreeing a Spring goal.
Chris, I like this approach and plan to give it a try. Question: If your backlog still has EPIC sized stories in it, how do you see this working? I could see that the lowest story (leftmost story) could be 20 or higher. In this scenario, I don’t really see you being able to produce an effective sized release backlog until you break stories down further. Comments?
Thinking on this a bit further, we like to identify internal drops (after x number of iterations we produce a drop that is potentially shippable) for a given release. These drops are for the purposes of getting feedback prior to “releaseing”. We can take this feedback into the next iteration or next drop. I could see using this method for EPIC stories we target per drop. So for a drop we have a plan for that drop with the stories we want to deliver. I would use this process for just those stories to help further break down the stories and size them. Thoughts?
Epic stories are fine to have in your backlog, so long as they are not near the top. The stories at the top should be small enough that the team can complete 4 to 6 of them each week. AsI’d you look further down the backlog, you want the averageCheers size to be increasing. That is, you generally don’t want to break all the stories down too early; it’s took much work, you probably don’t know enough yet, and things will change.
As for your approach of having frequent “drops” that are releasable but not necessarily released, that’s cool. I’d want to be getting those in front of real users to get their feedback. I’d also want to look for ways to release more frequently.
Cheers,
Chris
Hi, people!
We’ve tried this approach many times and found it very effective, comparing to the planning poker. At least, this technique reduces discussions, which are often noisy…
Do you know if there is an online solution for distributed teams?
If you don’t know any, would you be interested in such web-application that enabled distributed teams to play estimation game in a convenient way?
Best, Z
Almost year passed, and since that we were able to develop the online estimation game for distributed teams.
Feel free to check it out:
http://agile-values.com/
I will gladly answer any of your questions via email: vitaliy.zurian[at]gmail.com or skype – zurian.vitaliy
In the example above, you say:
“Mark places the “21” card above a story. Malay is next. He shakes his head, then removes the “21” card Mark just placed. “I think this is actually a 34,” he says, naming the next-highest number in the Fibonacci sequence. He replaces the “21” card with the “34” card.”
Could Mark have placed the “21” card between 2 stories AND placed the “34” card above a story. This would effectively merge Mark and Malay’s actions into one move. Would this still count as a single move?
@Valentin Yes that would be a legal single move in the game. 🙂
How do you estimate in successive backlog refinement sessions? Do you put all the cards on the wall again and declare them as “not moveable” (because re-estimation is is a no-go)? Or do you start with a blank wall? If you start with a blank wall, how do you ensure that the stories are sized the same way as during the last game (so that a 5 from this game is approx. the same size as a 5 from the last game)?
I think the most telling comment above was the one advocating this technique because it reduces “noisy” discussion. You *want* the discussion. The primary purpose of planning poker is *not* to get the estimate: it is to get the team to come to a shared understanding of what a given PBI or SBI does or is. The estimation is a side effect which, individually, is quite imprecise.
Another point of planning poker is that no one can be a lurker. If someone with testing insight is feeling disempowered by those driving the estimate with engineering concerns, she might not speak up on a given item. It’s possible to go through this whole exercise, ranking each item on the input of only one or two people.
Pingback: Relative Estimation Method for Distributed Teams
Hey Hillalry, thank you for your post! Have you heard also about the Zmey Planning (http://www.agify.me/the-zmey-planning/)? It’s quite new and not so popular estimation technique. In addition to complexity it also takes into account uncertainty and vagueness of requirements – all of which might have significant impact on the estimates. Probably it won’t be as fast as the team estimation game but still worth looking. Cheers! 🙂
Pingback: Tuning up Scrum Approach | Marat Kinyabulatov blog
I learned this game at the New Orleans Scrum Gathering in 2014, in the context of estimating Business Value – I used it with great success a couple years ago, and so glad I found it again! One of my favorite tools.
Thanks for sharing! We love hearing that people find this useful. 🙂
Great game, helped us a lot! Our estimations were almost always inaccurate, but this took us back on track.
We also played a card game for improving our backlog refinement and requirement analysis, so please give it a try https://medium.com/@dakic/35-cards-which-will-improve-your-backlog-refinement-process-and-engage-every-team-member-54f929fdd282
It is an awesome alternative to planning poker, especially for fresh agile teams.