Nice blog! More people should read it. If you want, you can register your blog Pokerweblogs.com .It is free and and it automatically updates when you do an update, so visitors of our site can see when you updated your blog. The big advantage is that it will attract much more visitors to your blog.
Greets Peter
The first part reminds me of the āaverage of 3 independent estimatesā technique used to estimate the range for artillery or mortar. Apparently this works well in practice.
Another good technique for estimation attempts to weight each task estimate by the amount of uncertainty of that task. So the time estimate would be weighted by 1 for a module that can be coded without thinking. If the task is using an unfamiliar technology, then the time estimate would be weighted much higher. I find the exact numbers are unimportant but the introduction of uncertainty definitely helps!
I think an important distinction is that between estimate and guess. Guess is just arbitrary while an estimate - if the person worth any cent as an engineer - is based on past experience with similar tasks. In practice the estimates achieved with planning poker become better with each release cycle if the team members are sufficiently experienced in working with each other. So an estimate is not necessarily a guess but it could be. As a project manager it is your duty to talk to your people and find out.
Planning Poker definitely supports collaboration and team learning. The discussions around specific tasks help all people in the team to challenge their assumptions. In the end the estimate becomes better - but it is still not a prediction - and the buy-in from the team is improved as well.
A printing template for creating the card game yourself is available for free at http://www.agileutilities.com/products/AgileAuction
Kind regards,
Manfred.
@Curtis (first comment): Make that 11 (will be 12 in a few months), I think it now qualifies for a case study on how Project Management went wrongā¦
I have to agree with Manfred - the benefits from planning poker also come from the discussion and shared decision - it is not just a numbers game. Sometimes getting everyone to input to the conversation is the most important thing.
btw you can get really good quality cards from www.agilehardware.com - you can use them again and again
Hi all,
you can buy nice Planning Poker Cards at the homepage of agile42.
http://www.agile42.com/cms/pages/poker/
Have fun
Marion
Nice post. One additional advantage of planning poker that I recently blogged about, http://onemoreagileblog.blogspot.com/2009/03/using-planning-poker-to-ensure-common.html, is that it helps create a common understanding of a story at a team level.
In short, if all team members throw around an 8 and one throws a 40, then the one guy has an incorrect assumption of the work or what the scope of the story is, or that person knows something the rest of the team does not. Either way, itās a a great starting point for discussion.
Similarly, if the numbers are all in the same ballpark, move on. In these estimation/planning sessions, the goal usually a high level estimate to help plan, it is not a design or tasking session.
Iām useless at estimating and I know itās for 4 reasons.
i) I donāt track historical data.
ii) Iām over-optimistic even when I think Iām being pessimistic.
iii) I donāt start by really, properly designing.
iv) Iām not assertive enough to make sure I get the resources I need quickly to make sure I get the debugging done quickly.
Planning poker sounds almost like socialized groupthink, Jeff. A clever way to CYA through dialogue and consensus, almost like a manager-based dissertation on estimation. The comparison to the Oracle of Delphi is merited.
However, the tool by Mr. Spolsky sounds very promising. The only trouble is getting others to focus and donate time to the next project while they are focusing on this one. It is hard to ask for more seemingly unimportant documentation when the sun becomes a quaint visitor that comes up and goes down while you are at work.
I must say I disagree. Are you doing Agile development Jeff? Have you used PlanningPoker on a live project?
I do agree with the importance of historical data, but not in the way itās described here. Focusing on a single person, how good he is to estimate and how reliable he is of doing his work? Do you want that? I certainly donāt! I prefer looking at the team and not the individual. When we do Agile development our historical data is our velocity. How much work (or how many story points) can our team do in one sprint.
When it comes to estimates I donāt really care if the estimate on one single item is accurate or not. What I care about is that our team actually manage to complete the amount of story points we committed to for one sprint or iteration.
āWithout appreciating the power of historical data-- youāre likely to keep repeating the same estimation errors over and over.ā
I say: āPlease keep repeating the same estimation errors, because that will let us continue the deliver on time!ā
Why is that? Well, thatās where the Agile approach has its advantage. Over time the estimation error will be washed away by the velocity. As long as you stick to your estimating mistakes, the team will only commit to what it actually is able to achieve, and that will be more and more accurate over time. Why? Because we learn by our mistakes. The first sprint my team committed to, we learned that we committed to too much, so we committed to a bit less the next time. Later we committed to less than we were able to do, so next time we committed to more. At this time we all have a feeling of how much weāre able to commit to and weāve become very good at it. Weāre still not hitting the estimates on an individual story or feature, but who cares as long as we deliver at the end of the sprint!
āThereās nothing magical here; itās the power of group dialog and multiple estimate averaging, delivered in an approachable, fun format.ā
Average isnāt really the point. Letting people with different opinions, conceptions and knowledge of the story to estimate is. Someone might (and probably do) know something that you donāt, and planning poker is a way of surfacing this knowledge.
Planning poker sounds hilarious! At the moment, the company I work for (a design/development/marketing agency) use a program called Gemini (http://www.geminiplatform.com). Iām not sure if you have heard of it?
Itās quite useful but unfortunately I donāt get to use it to create estimates as Iām not a developer but I will also show the development team this (maybe theyāll stop playing Age of Empires 2???) and see what they think!
Jeff, thank you for this article.
Graphs provided here are quite impressive and they actually reflect the real-world scenario.
Personally, I mostly prefer the Team Estimation Game method by Steve Bockman. He has published a small book recently, describing this method. It works quite well for experienced teams.
Otherwise, on the daily basis, I am using this Planning Poker Add-On for JIRA.
Nice introduction to the Planning Poker methodology. Iāve found that playing physical cards brings a lot of fun for the team members. The problem appears in a distributed team. In this case if you use JIRA I recommend trying one of plugins on this list: https://marketplace.atlassian.com/search?q=poker. Using an add-on you can make your planning poker sessions less iritating so there is a bigger chance that your team will do them long-term.