We have found it useful to size stories based on their relative complexity. More complex stories will
take more effort to complete. Feature complexity typically relates to the degree of interconnectedness
of a feature. This can be its own inter-connectedness or the number of connections to other features.
Interestingly enough, it takes about the same number of words to describe a simple story as it does to
describe a complex story.
Challenges in estimation
Some of the biggest challenges we have in estimation include:
- Too much detail
- Doing design while doing estimation
- Too much precision
- A reluctance to commit to the estimate
We have to remember that estimates are really just our best guesses of the effort required based on our
current information. We’ll have more information later and will refine our estimate then, and as we go
We have found it easier to make estimates based on a value relative to another estimate. In other
words, it is easier, and more accurate, to say “feature A will take twice the effort feature B will” than it
is to estimate features A and B separately. A simple way to do relative estimation is with a game called
– As far as we know Steve Bockman invented Team Estimation.
Team estimation game play
The “rules” for team estimation are very simple:
- Place your story cards in a pile on the table. Take the top card from this pile and place it on the
playing surface a foot or so away from this pile.
- The next player take the top card off the pile and places it relative to the first card based on size.
She can place it to the left if she feels it is easier, underneath it if she feels it is of the same size
or to the right if she feels it is more complex
- In succession, each play can either:
- Play the top card from the pile as just described
- Move a card on the playing surface (i.e., declare their disagreement as to the previously
stated size of the story by moving it to a different column)
- The above step is repeated until no more cards remain in the pile and no player wishes to move
Throughout this time, anyone is free to invoke others in conversation about why they are moving cards
and what they think about the size of the stories. Remember, however, that we are just making
estimates, so conversations to help clarify what the stories are is useful, but getting too hung up on the
exact size of the estimates is not worthwhile.
The following diagrams illustrate how the story cards are arranged on the table. Figure 1 shows how the
cards are laid out at the beginning.
Figure 1. Story card layout at the beginning of Team Estimation
After a few cards have been played, the story cards might look like those shown in Figure 2:
Figure 2. Story cards after a few have been played.
At this point, possible plays would be to:
- Take a card off the top of the deck putting it under any existing story, or creating a new column
to the left, between any columns, or to the right
- Moving any story into an existing column or creating a new column to the elft, between any
columns, or to the right
When you move a story to another column you are basically saying “this story has been misestimated.”
For example, figure 3 shows a possible play of a card (moving the card from one column to another). In
this case, it means that don’t think the card being moved is significantly larger than the stories in the
Figure 3. Card play indicating that someone thinks a story is currently mis-sized.
Finally, we get to the point shown below:
Figure 4. Possible card layout after all cards have been played.
At this time, the number of story points for each column can be assigned. These should be based on
what you consider to be allowable story points. We like using the sequence:
0, 1, 2, 3, 5, 8, 13, 20, 40, 100, 200, 400, 800
Figure 5 shows labeling the columns with the estimated story point sizes.
Figure 5. Estimated story points to use for each column
After these are agreed upon, these story point sizes should be written on each card.
Team Estimation for MBIs and features
While we have described Team Estimation for stories, it should be clear we could use it just as well for
MBIs and features.
Advantages of Team Estimation over Planning Poker
Faster and more fun
Prior to learning about Team Estimation, we had used a technique called Planning Poker. We have
found that Team Estimation is faster, easier, more fun and that people tend not to get bogged down in
too many details.
When not everyone can estimate the entire item
Planning poker requires that everyone can estimate all of the items. In reality, however, two variations
- Some people are needed to estimate parts of an item. Although there isn’t the role of tester in
Scrum, some teams have people who do more testing than development. In this case, those
doing the testing may only be able to estimate the testing role. In this case it be necessary to
estimate the testing effort separately.
- When only certain people have the capability to implement certain items we can have them do
the estimates within the context of the other estimated items
Part of the advantage of Team Estimation is that it works better than Planning Poker when team
members can’t estimate all aspects of a story. For example, even if a tester can’t estimate how long it
might take to write a story, they can make a reasonable estimate as to the relative complexity of one
story to another.