PMI Sites
Disciplined Agile

# Team Estimation

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 along.

## Relative estimation

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 “Team Estimation” created by Steve Bockman.

## 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)
• Pass
• The above step is repeated until no more cards remain in the pile and no player wishes to move a card

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 left, 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 leftmost column.

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 sometimes occur:

• 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.

## Recommended resources

This chapter was an excerpt from FLEX for the Disciplined Agilist: FLow for Enterprise Transformation (online book). It has been edited to fit into the Disciplined Agile Value Stream Consultant workshop. The Table of Contents for the book is here.