The best way teams I have been on have found to estimate via a group is Planning Poker.
There are many benefits related to planning as a group (see my previous post on this topic for more). One thing that was difficult to grasp for me at first, is the idea of group estimating. Have everyone estimate each task? Even tasks they know they aren’t going to be responsible for? Yes! The collaborative nature of group estimating helps further dig up hidden features/assumptions as well as provides other benefits.
Teams I have been part of have tried a number of different ways to group estimate like:
- Group determines (informally) who they think the task is going to be completed by, and defers to that person’s estimates.
- Group members all write down a hour estimate on a piece of paper, let everyone know what they thought, and then negotiate until some consensus is gained.
- Play planning poker for estimation.
- All were used to some success level, but the first two generally took much longer to complete the estimation process and also reduced group ownership of all tasks to more individual ownership of certain tasks. In one instance, the negotiation process for one estimate (not the details about the estimate) took over 30 minutes, and even after that time, we just took the highest estimate to be able to move on.
Looking for a better way, the team discovered Planning Poker. Here are the high level details:
Each team member has a set of ‘cards’, each with a single number. We use a variant of the Fibonacci sequence for card values (1,2,3,5,8,13,20,40,100′).- A item to be estimated is read to the group. Any team member who has questions about functionality/etc. are encouraged to ask their question(s). This continues until all questions are answered the best they can be.
- The group facilitator asks each team member to pick a single card. (Says: ‘Estimate!’) The card is not shown to other team members at this point and verbal estimates are avoided to reduce the chance of influencing other team members.
- All team members estimate (minus the Scrum Master and Product Owner if they are in the room)
- Once all team members have a estimate card, they are all flipped over so all can see.
- When there is a significant variance between estimates the person with the highest estimate and also the lowest estimate are asked to briefly explain why they picked the number they did. This usually exposes differing assumptions by each team member and allows for some quick discussion on which assumptions are valid.
- The team is then asked to re-estimate.
- This process if repeated until there is group consensus.
- Side note: This Planning Poker in detail page has a detailed outline of the process if it’s totally new to you.
A few tips/takeaways from my experience to help with playing Planning Poker:
- It rarely takes more than two or three rounds of estimating to have total group consensus. Yes… Really!
- Invariably when starting group estimating in general, team members will ask if they can ‘abstain’ from estimating some tasks. We have chosen as a team not to allow this. All team members need to participate and do the best that they can. This has helped all team members get better at estimating tasks they usually wouldn’t be asked to participate in as opposed to relying on specific experts and disengaging.
- If there is a small variance in estimates (3/4 of team picked 5 and 1/4 picked 2 for example), the team will discuss amongst themselves what they think is best and usually pick a number instead of doing another round of estimating.
- As a team, we have chosen to stick with estimates that correspond to numbers on cards. This eliminates the tendency to say: “you have 5, I have 2, lets just average them out to 3.5 and use that estimate”.
- We eliminated the 1 and 3 cards, as we found the difference between 1,2,3,5 to be too small to be concerned about as a team. This further encourages ‘bucket picking’ even at the low end of estimating to validate that we are really just sizing activities, not committing to specific time frames. (This decision has been debated a few times since in sprint retrospectives, asking to put the 1 and 3 back, but the team has decided to keep them out for now.)
- Have a way to limit question/discussion length prior to estimation. Some times team members can get caught in the details and ramble on for quite some time. I have seen some groups use a 2 minute timer that any team member can start, to limit the current discussion point of which when the timer is done, a round of estimation is required, keeping the process moving. Point here is: group is not trying to precisely estimate the tasks, but instead they are sizing them and that just needs to be ‘within the ballpark’ as the main value is gained in that short amount of time.
- Consider a ‘I need a break’ card. Some Planning Poker decks have a picture of a pie on one card, meaning ‘I need pie!’ When this card is shown, the group takes a mini-break. Group estimation can be quite taxing, so breaks are important to keep people fresh and avoid the pitfall of ‘lets just get this done’ estimation.
- Like most things, the first few times your group uses Planning Poker, it will take longer to get consensus, but over a number of sprints, estimation goes much faster as the group gets comfortable with the process in general.
Next up in this series, my take on how to best manage Sprint backlog task allocation to team members.