10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
Interview
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Nils Haugen on Planning Poker
Interview with Nils Haugen on Jul 27, 2007 Length 00:13:10
Summary
In this short InfoQ interview, Nils Haugen spoke with Floyd Marinescu about the "Planning Poker" technique he relies on to improve team estimates. Having consciously experimented with it for a while, he described this simple practice and why it works: by making space for team members to each contribute their own perspective. In this way, it's good for estimates and for teambuilding.
Bio
Nils Haugen is an agile developer and coach with Objectnet in Norway. He's worked with large distributed o-o apps in various industries since 1998. Nils worked with with XP/Agile teams at ThoughtWorks, and is an experienced conference speaker on topics in Java and Agile software development. He holds a MEng degree in Computer Science from the Norwegian University of Science and Technology.
In this short InfoQ interview, Nils Haugen spoke with Floyd Marinescu about the "Planning Poker" technique he relies on to improve team estimates. Having consciously experimented with it for a while, he described this simple practice and why it works: by making space for team members to each contribute their own perspective. In this way, it's good for estimates and for teambuilding.
Bio
Nils Haugen is an agile developer and coach with Objectnet in Norway. He's worked with large distributed o-o apps in various industries since 1998. Nils worked with with XP/Agile teams at ThoughtWorks, and is an experienced conference speaker on topics in Java and Agile software development. He holds a MEng degree in Computer Science from the Norwegian University of Science and Technology.
This is Floyd Marinescu from INFOQ at the Java Conference. We are here with Nils Haugen who is known to be quite a poker player and has a system for planning a perfect poker game. Nils, can you tell us a bit about yourself and about your system?
Sure. The best thing about this is that you can actually play poker at work and the poker I play is an agile technique used by agile teams to allow a group of people or a whole team to estimate the functionality they are to deliver together. And estimating with a group of people is beneficial compared to having just an individual person estimate because the expert or the individual estimating always estimates with his background and his abilities to solve the task, and thinking terms of how he would be able to solve the task and how long that would take; whereas when you do it as a group of people you can get the team's average ability to solve the task, which is much better.
Planning poker is sort of a semi-structured way of a deciding on the estimate together as a team and the term was coined by James Grenning in a white paper in 2002, but the technique has also been used other places, and is described in Mike Cohn's books on User Stories and Agile Estimating and Planning.
Planning poker is sort of a semi-structured way of a deciding on the estimate together as a team and the term was coined by James Grenning in a white paper in 2002, but the technique has also been used other places, and is described in Mike Cohn's books on User Stories and Agile Estimating and Planning.
The way it works is that you have a customer present to the team each piece of functionality, each user story, and talk about why the business needs this, the background, how they expect the system to behave and then the developers can ask questions and start discussing together what they need to do to the system in order to change it to solve that functionality. While they are doing that, each individual developer knows that when they have all the information they need, they will all be asked to estimate how long this will take and they will estimate individually at first, and the way they do that is they have a stack of cards with fixed estimates written on them, so there would be one card saying one for one day and then two for two days and three for three days and maybe they will decide that if the task is greater than three days it is too big and it needs to be split up. Each developer will decide on their card and then they will reveal their cards simultaneously, and that has certain benefits.
There will always be some diversity, different numbers, so the person with the lowest estimate and the person with the highest estimate will each be asked to justify their estimate. The whole point with that is just to bring up more information: could be that the person with the low estimate has thought of some way we could do this more easily, maybe by reusing some functionality in the system that he/she knows the others had forgotten about; and maybe the person with the high estimate remembers some additional tasks that need to be done in order to accomplish it. And then they can do multiple rounds of poker in order to get consensus for an estimate, where they will see that they quickly will narrow down to a team estimate. Compared to more unstructured group estimation, one of the good things is that by revealing the individual estimates simultaneously there is no "anchoring effect," and anchoring effect has been shown to be present in many different circumstances.
There will always be some diversity, different numbers, so the person with the lowest estimate and the person with the highest estimate will each be asked to justify their estimate. The whole point with that is just to bring up more information: could be that the person with the low estimate has thought of some way we could do this more easily, maybe by reusing some functionality in the system that he/she knows the others had forgotten about; and maybe the person with the high estimate remembers some additional tasks that need to be done in order to accomplish it. And then they can do multiple rounds of poker in order to get consensus for an estimate, where they will see that they quickly will narrow down to a team estimate. Compared to more unstructured group estimation, one of the good things is that by revealing the individual estimates simultaneously there is no "anchoring effect," and anchoring effect has been shown to be present in many different circumstances.
So an anchoring effect is some person giving an estimate or an expectation on how long something will take; then that has an effect on all the people trying to come up with their own estimate for how long it will take. So if somebody says: "This is probably five days", then the others will seldom go a long way from five days. It will be like four days, four and a half days but not one day or two days. And that effect is there, even though it is stated or the person putting out the anchor has no background and no authority as to how long it should take. It could be the customer, for instance, saying that: "This should be an easy one. You could do that in one day, right?" And by doing that he affects all the estimates given by the developers. So by revealing the estimates simultaneously you avoid that effect and that should make the estimates more accurate.
You have described how to plan one user story, so how do you put all this together into a wider planning session?
We can typically do this at the start of the release, in the release planning. And we will go through each user story and do the discussions and planning poker to come up with the estimate, so that the customer can pick which stories to do for this release; but we could also use it for iteration planning and do it at start of each iteration, and what I have seen in the teams where I've introduced it in iteration planning is that the actual number that the team comes up with is not really that important. The really beneficial thing is that the team gets to have this discussion about how they are going to solve the task and decide how it should be implemented and it doesn't matter who actually does it because the whole team is able to contribute with their ideas of how to do it and they sort of define the scope of the task better than they would with individual estimates, and also can agree in some overall quality of the solution to the task.
It is a great technique; teams really seem to love it. An extra benefit is that it's a very efficient way of doing your estimates and the team likes it because they all get to contribute, they feel more ownership of the estimates, which is really good; project managers love it because it doesn't take as long as doing a more unstructured approach to estimating. There might be side effects that we are not really aware of yet, so we are doing more research in order to discover those. We have seen some indications that the scope tends to increase after the team discussion, so the members of the team will bring up different issues and the estimate will cater for all those issues and solve the bits and pieces of that. Maybe initially you wouldn't have thought of putting those things into the task but we have to do more research in order to see how that technique affects the estimates in other ways. From the research that I have been doing it seems like planning poker estimates are more accurate than the unstructured group estimates which is really good for planning, makes better plans.
How do you deal with the "alpha male" developer, the one who is far more experienced , and people tend to want to do whatever he says because it's safer to believe and on the other hand how do you deal with the beginner, who might tend to over-budget everything?
That's interesting because other research has shown that the experts will often be overly optimistic about an estimate, so they will think it will take a lot less time than it really will take, whereas beginners or people who don't' know that much about how to actually solve the task will actually do better estimates because they are using a different technique for arriving at that estimate; they are trying to compare this task with tasks they know they have done in the past and try to see if there are some similarities or if they should be roughly the same size, and then apply those historic data about how long those other task took to do, to maketheir estimate; whereas an expert would do more a bottom-up approach and think about all the things that need to be done: adding a new database table, adding some persistence logic, some change to the UI - and how long each bit will take and just add it up to a new estimate. So, the combination is good when you get both perspectives on the team, and it is actually good that we all contribute to the estimate not just the person that feels like he knows the most about that particular task and how to solve it.
I think most teams either use expert estimates or individual estimates where maybe the lead developer or the architect will do the estimating. That is probably the most common sort, overall in software engineering.
I have also seen a lot of agile teams doing more unstructured group estimation, where they bring the group of developers together to do the estimates, but someone has to come up with a suggestion for an estimate and then they ask for consensus, and when one person comes with an estimate first that puts up the anchor. There are also models you can use for arriving at your estimates, which I don't think is commonly used in agile projects. I guess planning poker might have been inspired by techniques like "wide-band delphi", where you also estimate individually, but the estimates are anonymous and you need software in order to do the whole estimation process. Individual or expert estimates, unstructured group estimates, are probably the most common, so I would recommend trying out planning poker and see how the team likes it and also keeping an eye on what happens to the estimates, if the accuracy improves or not.
I have also seen a lot of agile teams doing more unstructured group estimation, where they bring the group of developers together to do the estimates, but someone has to come up with a suggestion for an estimate and then they ask for consensus, and when one person comes with an estimate first that puts up the anchor. There are also models you can use for arriving at your estimates, which I don't think is commonly used in agile projects. I guess planning poker might have been inspired by techniques like "wide-band delphi", where you also estimate individually, but the estimates are anonymous and you need software in order to do the whole estimation process. Individual or expert estimates, unstructured group estimates, are probably the most common, so I would recommend trying out planning poker and see how the team likes it and also keeping an eye on what happens to the estimates, if the accuracy improves or not.
I tend to do a lot of the XP practices, but also Scrum, but to me personally the important thing with agile are the values, we have to all the time focus on: "Is this actually delivering value to the customer?" and trying to minimize the things I would do that do not add value and do more of the things that actually bring value to the customer; once you are sharing those values it is easier to pick up which techniques and which practices to use in your context, in your project for your customer because every project has their own sort of challenges in terms of how they can interact with the customers and which development techniques they can use, so understanding the values, I think, is the key thing to agile.
- This article is part of a featured topic series on Agile Techniques and also Agile
- See more Agile Techniques content at: http://www.infoq.com/agile_techniques
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Case Study: IBM's Agile Transformation
SCM best practices for multiple processes, releases & distributed teams
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Is poker a team sport?
by
Steven Devijver
Posted
Re: Is poker a team sport?
by
Deborah Hartmann
Posted
Is this confusing estimating with planning?
by
Jim Leonardo
Posted
Re: Is this confusing estimating with planning?
by
Amr Elssamadisy
Posted
Re: Is this confusing estimating with planning?
by
Barre Dijkstra
Posted
Re: Is this confusing estimating with planning?
by
Deborah Hartmann
Posted
Re: Is this confusing estimating with planning?
by
Manfred Lange
Posted
Re: Is this confusing estimating with planning?
by
Michael James
Posted
Planning Craps
by
Deborah Hartmann
Posted
-
I thought this game is about bluffing and not trusting what the others are saying/doing.
I think this planning game is not for shy people. -
> I think this planning game is not for shy people.
I can see why you'd say that - similarly, you could say Agile itself is not for shy people. However, I've seen shy people happily embrace Agile... the key is to remove judgement from the process.
So, in planning poker, if everyone says "4" and the shy person says "2" they will be invited to share what they know. Perhaps it turns out they see a different way to do it, which is great!. Without freedom to speak freely, this person may not have contributed this idea. But with planning poker, there is a way for them to do so without having to "butt in" to the conversation. There is an explicit invitation to speak in planning poler, which I think helps shy people learn to trust their team mates. Conversely, it teaches more outgoing team members to listen to this quiet person, to value their input.
It is important that the person with the different estimate is valued for bringing different information to the team, rather than ridiculed for "not getting it". If, in fact, it turns out they didn't "get it", they will realize it naturally as the team discusses their idea, there is no blame involved. The discussion is about ideas, not individuals - this builds trust, which is essential to the function of an Agile team.
Without trust, yes, the shy people on a team will remain silent and real teamwork is thwarted. But many Agile disciplines are specifically designed to build trust. -
Pet peeve:
Estimating and Planning are different. This is estimating.
To be hideously short about it: Estimate= How Much; Plan= How Long.
I think its critical to know which you are doing when for the same reasons that we care about abstraction in code. -
yes - but wouldn't you agree that estimation is one of the important pieces of information to plan effectively?
-
I have used planning poker myself as well as introduced it with clients.
I totally agree that it is about estimating (complexity) but I disagree that it is not planning.
The way I see planning poker is that it is for estimating complexity and thus in the end iteration planning.
When you know your teams velocity, in terms of complexity points per iteration, you can get a clear view what can be done in an iteration; thus the iteration planning.
My personal experience is that, after a baseline on complexity and velocity, estimations get more and more accurate and the in the end the estimations are way more accurate then any kind of "expert opinion estimations". -
> planning poker is ... for estimating complexity and thus in the end iteration planning.
I agree. Estimates are a key factor in iteration planning.
Teams typically also go into iteration planning knowing a) their real-to-ideal ratio (ex: takes real two days to do one ideal day's work) and b) their availability (who's on vacation, taking training, etc.). So when the team reaches the iteration planning meeting, the only thing missing to create a plan is the estimate. That's where planning poker provides the "ideal time" estimates to complete the equation.
In addition, there is a need for longer-term planning (done with a high degree of uncertainty, in Agile). I call this "release planning" and it's a different thing from iteration planning. -
Jim's point is well taken. It would be more accurate to call this game (which I use and love, BTW) "estimation poker." Estimation informs planning, but someone else (in Scrum it's the Product Owner) still has to make a call on prioritization. "Estimation poker" doesn't have the nice alliterative ring that "planning poker" has though.
--mj -
I got this really cool die at Agile2007 - flashy and electronic, does the usual "dice" thing - give you a random number. Perfect for Release Planning Craps!! :-D
-
Yes I agree, planning and estimating are two different activities. Here is how we do it in our projects.
Planning poker (we call it Agile Auction) is a tool or technique. It's outcome is a relative size for a task (can also be for a non-software project) in comparison to other known tasks.
A release (= 3 months) consists of a set of iterations. Before we start a release we do a release planning. It is based on high-level stories and high-level estimates. We know that we need to adapt as we go but we still spend enough effort to get a full backlog to which the team can commit. And the team is cross-functional so there are more than just developers.
At the beginning of each iteration (= 1 week) we use Agile Auction (aka Planning Poker) to confirm the estimates of the stories in the release backlog.
By monitoring how many stories are completed in each week we can track the progress of the project. We can also determine the actual velocity of the team and we gain an indication of how much of the desired scope will actually get delivered.
So estimating with cards is more about 'size' while the actual planning is more about the 'when'. Planning should also consider factors such as availability of specialists, change in size of stories if they are done in specific orders, business value of each story from a market or customer perspective, marketing value, and many more.
In summary we found that Agile Auction (aka Planning Poker) substantially helps to improve the accuracy of the estimate (still not predictions, though!), collaboration and team learning.
One question we are often asked is where to get the cards from. In the article one source is already mentioned. If you are looking for a free template to print and create the cards yourself you can also download it at no cost from www.agileutilities.com/products/AgileAuction
Kind regards,
Manfred.
9 comments
Watch Thread Reply