Once in a while, I get the opportunity to talk about planning-poker with various kind of people. I did implement it in variously sized teams, but it was often misunderstood by my hierarchy as «only a way to get estimations».
In my opinion, it is a very nice and simple management artifact, unduly reduced to estimating time and budget, despite the fact it's in fact addressing one (if not the one) of the most costly parts of any organization: communication between people.
Some background
Planning and estimating software development projects is tough, yet one of the most common things asked to a development team. The reason is simple, one always want to have an answer to the simple question «How much?».
Some people tried to apply techniques borrowed to construction; the same people once thought that two people can do twice as much as one in a given period of time; or that nine women would give birth to a child in one month.
But... No. Waterfall mostly died, everybody is shouting «agile» whenever they can, but people still want to know beforehand how much something will cost, yet will tell you that «we'll see later about the feature details, you know man, be "agile"...». Pretty cheap negociation technique, and will probably get you an awfull product.
A few really important thing to grasp about (software) product development:
- Velocity you can get is directly dependant on the team that will execute the work (and I don't talk about individuals, but the team as a group).
- Most often, and even if you have detailed blueprints of your application, the development process is undeterministic and things will be discovered allong the way.
- Software development is a bridge between art and science. It's using science as a tool, but it is a creative process.
If you're saying «this project needs 50 man-days» you're either a liar, or you forgot to say «to this exact team I know very well, according to past events and according to the fact our understanding of the project today is not too far from where it will get». Most of the time, people are liars, and don't even know it. They don't lie because they intend to harm, they lie because they don't know but still wanna say something.
So what? I don't want to be a liar. But I need to say something. What can I do?
Meet Planning-Poker
Planning poker is a simple «serious game» (well, no, it's not a game, in fact...) often used to make estimations of amount work that can be done in a «sprint», meaning a short iteration of development.
More widely, it can be used as a tool to estimate any task that is either not completely definite, or any task on which time spent to completion is highly function of who's executing it.
It's a simple artifact to use with your whole team, that will be used to calculate a backlog's complexity, an arbitrary statistic measure that can be then used to make predictions based on what already happened.
A simple way to run it is to have all team members (players, let's say) have a hand of around 10 cards with fibonacci numbers on it (1, 2, 3, 5, 8, ...), and ask them how hard is each task compared to the others. Each «player» should assign a complexity value for the task and everyone should reveal it at the same time, to avoid various bias of human influence in communication. Put shortly, everyone must make a choice, only one choice, and by himself.
For each task, two things can happen.
First possibility is that everybody agrees, or have a pretty close estimation, and you can just grab the number (or averaged number) and jump to the next task (if you're using some kind of kanban, you can write it down right on the card. If you have a web-based bug tracker, you should find a way to save the complexity number attached to the ticket).
The second possibility is that there is no consensus, and then interesting things happen, because you need to get to one. My way to do it is to take the two people that chose the most extreme values, and let them debate why they think it's so easy or so hard to realize. Once they have a better understanding of the task a second round happen and except for very complex tasks, you should get a consensus pretty soon.
What to do with all those numbers? Easy. Make a sum, compute how much of those points are resolved the first few days, and with a simple division you'll get an estimation of the overall time needed to resolve the whole backlog.
It's basically statistics, so you'll get more precision with more real world data, but you should have a vision on the time budget you need to allocate even after just a few days of work.
What you should not do
Don't try to get this value for single persons by taking the complexity resolved per day average and divide it by number of people in the team. The whole process works because the team work as such, and you're most likely not to get the same value if you take only one as "a team". Use it for what it's good.
A corollary of this «don't» is that you can't say «Hey, I need to achieve the project 1.5 times faster than the estimation gives me, so i'll just do the maths and I'll just make the team grow by 1.5». That does not work, and you can even lower the complexity-per-day (also called velocity) of the team by doing so, at least in the first days or weeks.
A team should be able to work together as a group, taking in consideration the work of each member as a part of the whole, using efficient communication. When you double one team's heads count, what happens first is that the cost of communication raises: merging code is communication; understanding the standards for one project is communication; feeling the right balance between code quality and intellectual waste is communication; not having two people solving the same issue is communication; understanding the business stakes is communication; etc.
That's why I think the most important role of planning poker is not estimating. Correct estimations is just a colateral damage you'll get for free.
Collective intelligence
Planning poker is a small amount of time dedicated to make your team's communication skills grow.
Planning poker is an inexpensive way to exploit the collective knowledge of a team at its maximum.
How damn? Why?
Think about what happens when two members of a team debates after having given complexities of «2» and «13» on the same task. What they will say can sound like the following:
Jane — «Hey, I think it's easy to do because we have some framework that can scaffolds this user interface for us in a breeze.»
John — «Oh really? Did not think about it, should make this a lot easier, but did you think about the impact on logistics department? They should be able to see quotations and invoices right when they're emitted, and they use a system that's a hell to interact with... I had a minor patch to apply on it last week and what should have took 5 minutes kept me busy for days...»
Jane — «Mmmh right, did not think about it... Maybe we should ask them if a daily export can be enough?»
You got the idea... What's happening here? The whole team is getting priceless information about the knowledge of each one on a given task. The tools that make their life easier, the gotchas about some external services... They even can start to make proposals on way to lower the development price...
Seniors in the team will dispatch informations that only them can use usually, juniors will make better contributions, and each one can concentrate on their real value, being members of one team, instead of being a few individuals acting as such in something their managers called a «team».
Isn't it worth it to waste two hours a week on getting better at working together?
I'm not a «tool» or «process» advocate, for the sake of it. As the agile manifesto would say, I value individuals and interactions over processes and tools. But that is exactly what it is.
Interactions between people. Efficient and fast. Using a small simple artifact that any smart child can learn in 10 minutes.
Still not convinced? Just invest some man-hours once and observe the result.
Photo credits: fitzsean cc by-nd