Estimation is hard. Part Two.
I covered the three main reasons I use Planning Poker last week. This week is about how planning poker plays out in an estimation meeting.
The best way I can think of to see how planning poker works is to show it. The estimation will be for a trip from Minneapolis to Chicago. The Product Owner has called her group of developers together to provide an estimate for the customer. The developers are all the people who will do the work on the trip. An analyst might be used to better define the trip parameters. A developer may be used to build the trip based on the parameters, but usually there will be more than one. Someone else may be testing a model of the trip to ensure it satisfies all parameters to the best of the teams ability. The people involved may or may not know a lot about the other roles present. For this exercise the important thing is that each person doing work for the requirement is present to estimate it.
At the start of the meeting the product owner explains the story. Someone needs to get from Minneapolis to Chicago. They need to be there in time for a meeting after lunch. They need to be back no later than the next morning. They cannot leave until the day of the lunch. Are there any questions from the group?
Maybe there are. The analyst might have questions to make sure there are no hidden requirements. Are they using a company car? Do they need to work on the way? Is the company jet authorized? The developers and testers might have questions as well. What are the expected traffic patterns along the route? Can we account for security and weather delays if they are flying?
Just as important as the questions for the product owner at this point is the discussion among the development team members. Even if the team is not cross-functional they are providing a single estimate. There is not a separate story point selected for testing than for development. The point value given is for everything involved in the requirement until it is released.
This discussion is not going to be allowed to go on forever. It should be time-boxed. I use a five-minute timer started after the product owner gives the description. When the time expires the meeting facilitator, an agile coach or the person acting as scrum master for instance, will ask if everybody is ready to make their first estimate. If the team is ready before this they can start sooner. If they really feel they cannot make an estimate I will often allow for one more five-minute discussion. (This has become less necessary as the team has gotten used to the process.) The facilitator calls for everyone to lay down a card. They are lain face down. This allows each person to give their actual estimate without being influenced by a subject matter expert or team lead. Once everyone has one down they are turned over.
the cards will show up with values from the following set: 0, 1, 3, 5, 8, 13, 21, 40, 100, ?, infinity, coffee cup. Usually an 8 will be an average sized requirement. Something that is essentially a non-issue would still be a 1. Even if it is a simple one-line change that is tested by looking at a text box it needs to be a 1. A 0 is for items with no effort. Maybe the requirement has been fulfilled by previous work between when it was written and when it was estimated. Maybe it will be filled by a different requirement that has to happen anyhow. 21 and 40 usually mean the requirement is to big and should be broken down. After breaking it to multiple requirements a new estimate for each one can be done, 100 is usually reserved for items that are epic in scope that the business may not have realized were so big. Infinity is for impossible items. A question mark means that person has no idea and a coffee cup means they need a break.
If there is more than one value the outliers should be asked why they put down what they did. This should be done under the five minute time box. After that, a new round is played. This will continue until the teams success criteria is met. Some teams require 100% matching. Some require that the minority people can agree to the value even if they feel it should be different. In our case we will take the majority if there are only one or two outliers, they are only off by one, and they are ok with the compromise. In extreme cases an item can be tabled for later or the team can agree on a value with low confidence.
The important thing to remember is that accuracy is secondary to understanding. If the team understands the requirement well their estimate will be good enough for story point estimation. Variance will come out in the averaging when velocity is calculated over time. It is also possible that the team will come to a new understanding of what an average requirement is over time. While there may be a temptation to go re-estimate some items in light of this, it is not necessary and arguably would be bad for the team.
That’s planing poker in a nutshell. We have customized it a little over time. The details for that will come as we continue our agile journey together.
