We all like games. They bring us together in fun and exciting ways. Our memories bubble over with excitement with all the great experiences we have from play games. What if we could brings games into the work place? What kind of games can we play? What benefit would the games bring?
Agile has given us the opportunity to add games into our work life so we can have fun and do work at the same time.
Planning poker is a perfect example of introducing a game to help teams come to a consensus on estimates for user story or themes.
How to play planning poker
- The agile project team (no more than 10 people. If great that 10 people then split into two team to keep the estimates low)
- User stories or theme
- Planning poker cards
- Open communication
- A facilitator
1. Give each developer that will be participating in the design, architecture, development or testing of the project a deck of planning poker cards. These cards will read something similar to 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 and 200. All cards should be prepared ahead of sprint planning and be readable from across the table.
2. The facilitator, typically the product owner or scrum master but anyone can facilitate, will read the user story or theme to in full detail. The estimators can ask the product owner questions for clarification. But keep in mind that additional questions may not increase accuracy. The goal of planning poker is not to base estimates on predictive future circumstances. Rather, the goal is to come to a valuable estimation as easy as possible.
3. After the reading, questions and discussion each estimator will secretly select a card they feel represents their estimate. Once all the estimators have made a selection they reveal their cards at the same time so all everyone can see each estimate.
4. Mostly likely the estimates will differ greatly. This is good thing. If estimates differ, the highest and lowest estimators explain their reasoning behind their estimate. Stress the importance that it’s the thoughts behind the estimate that we are most interested in rather judging that person with a personal attack.
Here’s an example, the highest estimator might say, “We will need to create new build scripts to include these libraries and this will impact the deployment to our environments. Also, have we identified all the dependencies of these libraries?” The lowest estimator might say, “Yes, we have identified those dependencies but I forgot about the additional build scripts.”
5. The group should continue discussing the story and their estimates just a few more minutes. The facilitator should take note of anything of importance and be sure to reflect on them during sprint while development and testing is taking place. Once the discussion subsides it’s time for all the estimators to re-estimate by selecting a card. Again, the estimate is made in secret until everyone has estimated, at which point they are turned over at the same time.
6. In most cases, the estimate will have come to a consensus by the second round. However, if the estimates are still out of sync then repeat the process. The goal is for all estimators to come to a consensus on an estimate for the user story. It’s a rare occasion for estimating to past 3 rounds. Continue as long as you’re getting close to a consensus. If you’re facilitating and you’re working on a four round of estimation and your estimators have drawn something like 3, 3, 3, and 4, then I will ask the higher estimator if he/she is willing to concede to a lower estimation of 3. The point here is reasonable consensus over accuracy.
Keep this in mind when you’re facilitating the discussion. Preliminary design discussion is acceptable and essential when estimating. However, lingering on design discussions can be a wasted effort. With that in mind, there are effective ways to time box the time spent on discussion to make we’re using are time efficiently.
7. Continue this process until you have estimated all of the items for this estimating session.
When should teams play planning poker
It is best practice for agile teams to play planning poker at three different occasions. First, there’s usually a team will go through the effort of estimating a large number of backlog items before the project officially beings. This is usually to get an idea of how complex a project will be and to get a pseudo-holistic view of project. It helps to secure funds that will initially start the project.
Secondly, during sprint planning a team will take on a certain number of user stories for their commitment. It’s always good practice to size the user story to validate the current estimate. Sometimes a user story needs to be divided and a quick round of planning poker will help to estimate the smaller stories.
Thirdly, during the sprint as user stories emerge they will need to be estimated by the team. It’s critical for teams to estimate these user stories as the come up because they could impact the current priority of the product backlog.
Why does planning poker work over traditional methods?
Now that you have had a taste of planning poker, it’s time to talk about some of the reason planning poker works well.
First of all, planning poker brings together all the people involved with the project. This means all the expert opinions will be available for estimating. Since the majority people involved come from cross-functional teams all the different areas of expertise will be covered. Better estimation is achieved by having the experts present.
Secondly, the passionate discussion during planning poker ensures that estimators will engage their peers to corroborate their estimates. This will improve the closeness of the estimates. This is especially so with work that has many uncertainties. Having to justify estimates has been known to result in estimates that satisfy the missing information. This is especially important to agile projects because user stories can be intentionally vague.
Third, the group discussion of planning poker leads to an average estimate from all the individual estimates, which yields better results.
Finally, it’s works because planning poker is fun to play.
comments powered by Disqus
Sign-up for our monthly newsletter.
Measure What Matters
Agile Blog RollThe Art of Agile
The Agile Executive
Agile Pain Relief
Succeeding with Agile
Planning For Failure
This Way Up
Rally Blogs - Agile
All About Agile
The Critical Path