An interesting pattern was revealed to me. I noticed it in my embedded team and with other teams who asked for help. Product Backlogs were not being estimated.

Teams were not estimating in points, days, nor even time. It is unclear what led to this lack of discipline. A consequence of teams not being able to say when something might be done resulted in other people setting deadlines for those teams.

Playing the Team Estimation Game

Demand for coaching was high and we were always being called in to situations. In looking around if I found a backlog with hundreds of items and no estimates, I would try to schedule a session for playing the Team Estimation Game. To play the game I would print out the Product Backlog first and then spend time cutting out each item. I would then place 8.5 by 11 paper around a table with the planning poker numbers on them.

Handing out portions of the backlog to each team member, we would start the session by silently placing items into the corresponding point bucket. The bigger the bucket, the higher the number on a piece of paper taped to the table. Team members were free to move items from one bucket to another. The team kept moving some items around and we noted these for estimating with planning poker later.

Consequences of the Game

The intent of playing team estimation is to quickly size an entire backlog. These teams went through over one hundred items in less than an hour. The technique is not as thorough as planning poker. Done silently, team estimation doesn’t invite the conversation found in planning poker. It does allow for a baseline sizing of the backlog. Team estimation can establish an historical base line velocity for a team if they estimate finished work as well.

Consensus is established quickly on the really big items and on the volatile items that need refining before they are ready for Sprint planning. It helps a team gauge the rate of progress and helps everyone conclude when to expect work to be done instead of forcing dates on people.