When creating a plan—whether it be a big project release plan or a smaller two-weeks' timebox plan—you essentially need to know three things:
- Tasks —What are the requirements? What do you need to do?
- Size — How big are these tasks compared with one another? How long will these take to complete?
- Priorities — Which tasks need to be done first because others depend on them? Which tasks are most important regardless of dependencies?
- Planning Poker - Agile Estimation for Dummies talk by Vineet at BarCampDelhi3 Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website.
- At first blush, this may appear to be a lot of work with little value. In practice, this is a very quick and simple exercise and it gets you to a decision point pretty quickly. The fact that it is a system makes it predictable, and the 10 minutes it takes to learn and implement will be recouped in your first sprint planning session.
It's very much like creating a recipe: assemble the right ingredients, measure them to the correct proportions, and then mix them together in the right order.
In an Agile project the prioritisation of tasks is done by the business. It is their project after all; they have the most information about value, they understand the market, they have an idea of what features should be delivered next. Prioritisation is not a decision to be made by the development team.
Planning poker is a common consensus-based technique to make estimations in XP. In Planning poker, estimations are made by using numbered cards that face down to the table. Thus, decision makers (in this case technical stakeholders) do not speak their individual estimations aloud but using the cards. A poker planning, or scrum poker session involves product owners or customers and editors. The session begins with each estimator holding a deck of value-based cards ranging in sequence. We recommend the following: 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100.
The size of each task, however, is something that the development team is qualified to estimate. If I want a new wall built in my garden whose estimate should I trust more: mine (the person who commissions the work) or the builders (who do this job day-in, day-out for a living)?
When planning, we use a tool called planning poker to help estimate the relative size of tasks.
Planning Poker Slideshare Download
Planning poker
Planning poker, or Scrum poker, is a very effective, collaborative planning tool that was first defined by James Grenning in 2002, and made popular by Mike Cohn, founder of Mountain Goat Software.
Each estimator takes a set of planning poker cards, consisting of a 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 and optionally a ? for instances where you simply have no idea), and ‘play' progresses as follows, the rules are pretty simple:
- Read out the next task.
- Discuss the task: The task is discussed by those who understand what it's about, so that the whole team gains clarity about what they are being asked to estimate.
- Estimate: Everyone selects a card representing how big they think the task to be. Once everyone has selected, we reveal our score at the same time. This is to prevent other team members' estimates influencing your own.
- Lowest vs highest: If there is not universal consensus, ask whoever scored the lowest and highest why they thought this was.
- Re-estimate: Given these new insights everyone re-estimates.
- Gain consensus: Once consensus has been gained that score is recorded with the task to which it relates. This consensus can be done by repeatedly re-estimating, but more often in our team if most have scored, say 8, and one member still estimates a 5, then she may simply say that they are happy to go with the rest of the group.
Benefits
Relative
One of the immediate benefits of planning poker is that it allows you to estimate tasks relative to one another. You may not be in a position to know exactly how long something will take to do, but it should always be easier to estimate whether it would take more effort or less effort than a similar task that you have already completed and know how long it took.
Think of it this way, it doesn't really matter if you measure the length of your desk in metres and centimetres, feet and inches, or even Post-it notes and pencils, so long as everyone on your team is also using the same scale.
Some teams use an arbitrary unit called ‘story points' where they know the size of one story point, others measure in ideal days. We estimate in ideal hours.
Planning Poker Slideshare Free
We also take into account how many people we anticipate will be working on the task. So if we think the task will take one hour with three developers then we'd score it as a three. Although it only occurred to me a couple of weeks ago that we also need to build in quality assurance/testing time into our estimates.
One general rule we have is that if a task is scored as a 13 or above then it needs to be broken down into smaller tasks. Large tasks are generally more complex and therefore harder to estimate with any degree of accuracy. Breaking down the task into smaller pieces removes some of this risk.
Equal voice
Another benefit is that this style of estimating gives everyone on the team an equal voice. I remember one of the first times we used planning poker when one particular task was discussed, it involved cleaning up a few directories in our media library. My colleague Steve and I estimated something small, like a 5 or 8. Duncan, who had only been in the job for about six weeks estimated 100.
Why so high, Duncan? Even though he was relatively inexperienced in terms of the job as a whole it turns out he had the most up-to-date experience of our media library, and he reported that it was a right royal mess. It would take a much longer time to sort out than either Steve or I had anticipated.
Equal contribution
Related is the feeling by the whole team that they have all contributed to the plan. And people often feel more committed to a plan that they have had input on. The result is a more dedicated, self-organising team.
Conclusion
We've found planning poker to be a very effective tool for estimating the relative size of project tasks. It allows the whole team to understand what work is coming up, and have their say on how simple or complex the tasks are.
It also allows us to chart the velocity of the team from sprint to sprint, which in turns helps us with future planning as it gives us a more accurate idea of how much work we are likely to complete from sprint to sprint.
More reading
Luis Goncalves, co-author of the excellent book Getting value out of Agile Retrospectives has written a really useful article about planning poker:
For a few months we've been starting to use Agile, and specifically Scrum, methods in planning and managing our Web projects at work.
This week we adopted a new practice: planning poker.
Like many teams starting out with Agile practices we didn't just jump in feet first and adopt every Agile method going; that would have been too much to take in. So we began with a few methods:
- Informative workspace
The photograph above, taken a couple of months ago, shows the planning board in our office — an information radiator — that shows us at a glance how many tasks are left to do, what's currently being worked on, what's in testing, what's done and (unlike, I would guess, most other Agile boards) what we're waiting for.
Multiple projects
By definition Agile really should be used by teams working on one project at a time. It's simply not efficient working on more than one because as soon as you start switching between different projects you lose time. One reason is that it takes time to get back up to speed with project B after working on project A.
However, some of us have no option but to work on more than one project at a time, as well as juggle support emails, telephone calls and the like. In which case you simply have to adapt the principles of Agile to accommodate more than one project, and essentially run them all in tandem as though you were working on multiple threads of a single project.
Karl Scotland, formerly Development Team Leader with BBC Interactive wrote a really useful paper back in 2002 entitled 'Agile planning with a multi-customer, multi-project, multi-discipline team' (DOC, 225 KB) in which he explained how he ran things at the BBC where they would regularly work on three projects simultaneously.
We currently have 19 projects on the go at the moment. Which is far, far too many and we need to do something about it. So this week we revisited our project backlog and introduce a new Agile method to the mix: planning poker.
Planning poker
The idea behind planning poker is very simple: 'planning poker is a consensus-based estimation technique for estimating, mostly used to estimate effort or relative size of tasks in software development' (Wikipedia).
Each member of the team had a pack of cards (I made our cards using Microsoft Publisher 2007 and a handful of skills) which have a sequence of numbers printed on them. They are quite often close to a Fibonacci sequence to reflect the uncertainty in estimating larger items. Our pack uses the sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, a ? (unsure) and a coffee cup (I need a break).
We then took each item in our project backlog and after an explanation of what was required we all took a vote on how difficult we thought it would be as a project, placing the cards down on the table at the same time so as not to influence another player's estimation by laying your card earlier than them.
Once voted, unless the group has a consensus the person who laid the lowest-value card and the person who laid the highest-value card explains why they thought it was easier (they've done this before, for example) or harder (what did the others miss?).
Votes are taken again until a consensus has been reached and then the team passes to the next task or project on the list.
Planning Poker Slideshare Tutorial
We found it a really useful exercise because it actively encourages everyone to speak and gives everyone an equal say in the decision-making processes associated with managing projects. We really quickly got to the core issues related to each project and at times an interesting spectrum of scores (13, 20, 40 and 100 for one project).
Our conclusion
Our next stage is to complete the scoring on the remaining 60+ projects, and work with our boss to prioritise projects. That should give us an overall score (estimate x priority) which will enable us to more accurately plan when we should schedule these projects and in which order. For example, you don't really want to be tackling three really taxing projects at once.
Oh, and it makes the task of planning much more fun.
If anyone wants a copy of the cards I made (in PDF format) drop me a note in the comments and I'll upload them for you.
More resources
Luis Goncalves, co-author of the excellent book Getting value out of Agile Retrospectives has written a really useful article about planning poker:
