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:

1. Tasks —What are the requirements? What do you need to do?
2. Size — How big are these tasks compared with one another? How long will these take to complete?
3. Priorities — Which tasks need to be done first because others depend on them? Which tasks are most important regardless of dependencies?

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.

1. Poker planning bring all such missing information to the table for discussion. Read my earlier posts on using story points to even out such differences. Even team finally agrees to go with higher number, scrum focus on honesty here. Say the team finished that story well before time, then they should pick-up something more.
2. Planning Poker 1. Associate Professor David Parsons Massey University David Parsons - Massey University 2. First developed by James Grenning “How to avoid analysis paralysis while release planning” The aim of Planning Poker is to create estimates in a short time and involve the whole team David Parsons - Massey University.

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.

When planning, we use a tool called planning poker to help estimate the relative size of tasks. 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.

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

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:

1. Read out the next task.
2. 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.
3. 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.
4. Lowest vs highest: If there is not universal consensus, ask whoever scored the lowest and highest why they thought this was.
5. Re-estimate: Given these new insights everyone re-estimates.
6. 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.

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:

Agile, Project Management, Scrum, Software Development, Technology

What Comes First?

Index cards for Saturday morning chores (alandd from flickr)

You’ve spoken to all of your stakeholders, maybe had a workshop or two, gathered all of the input, defined requirements and converted it all into stories, and now you have writer’s cramp from printing them all out onto index cards. You’ve now taken over the conference room and spread your cards out on the table so that you can organize them and figure what goes into your first sprint. So really – what stories come first? Marketing, Sales, Finance, and Operations all have their priorities. Your lead architect says that none of it can be done until the architecture is nailed down – and then of course there is the CEO and her view of what needs to be done first – Oh, and don’t forget the customers. It’s all important; otherwise it wouldn’t be on your index cards would it? Some things are definitely more important than others – but which ones? Scott Ambler says that 85% of all features built into software products are either rarely used, or never used at all. So as much as some stakeholders might think that a particular product feature is essential, it is highly likely it will end up being one of the 85% that go unused. One of the fundamental reasons for using an Agile methodology is to focus on the things that bring the greatest value, so how do you actually determine which stories provide the greatest value and are thus scheduled first? To be effective and obtain consistent, repeatable results requires a system or process that is quick, easy to use and consistently applied.

The quick answer is to rank all of the cards on a scale of 1 to 10, or 1 to 100 if you need finer differentiation, and then sort them in order from highest to lowest priority. This is a pretty common approach, but it is challenging to apply a single numerical value to what is usually a multidimensional question. Do you rank your stories by the CEO’s sense of urgency, the amount of money a customer will pay you to do it, what marketing says is essential, or to placate a cranky stakeholder? Any of these criteria might be valid, but how do you know which ones are more important than the others, and when does one criterion apply but not another? I found that looking at these choices from a two dimensional perspective, and by having guidelines for the application of each of two vectors makes the decision making process much more straightforward. You could in actually use any number of dimensions or vectors you wish, but using more than two causes the process to get bogged down in the fine details and makes the otherwise simple calculations more cumbersome. Perhaps more importantly, it is very difficult to represent three or more dimensions in a two dimensional world such as a computer screen or on an index card. So the number in this approach is two.

So now that you’ve decided to be merely two-dimensional, what are you going to choose as your assessment vectors? In truth, you can use any two you wish. I use Time as the first vector because time is almost inevitably the fundamental constraint on all projects and it is the one finite resource. Most importantly, Time is the basis for arranging and sequencing our work. Time for the purposes of this methodology, is also thought of as Urgency.

The following table lists a set of guidelines that are suggestions for selecting each one of the five possible Urgency (or Time) vector values. It is important to keep in mind that guidelines are suggestions, and you are free to define your own criteria. Regardless of what you choose, keep your guidelines as general as possible because the more specific and detailed your guidelines become, the less useful they will be.

Urgency

Planning Poker Slideshare Tutorial

So what about vector number two? I use Business Value. The category and the guidelines are purposely generalized so as to avoid debates about whether or not something is in the list and is thus applicable or not applicable as a criterion. It also leaves rating open to interpretation by different stakeholders so that the numbering system does not get gamed or used as a lever by different stakeholders to manipulate the process. Business Value could thus mean the amount of revenue that might be generated or lost, effect on brand or reputation, performance issues, security concerns, etc… It is up to the team to decide in each case what the Business Value guidelines should be, and how to classify each item.

Business Value

If you run an internal IT shop, some of the Business Value suggestions may not be relevant. If, however, you run a small bakery and your project is opening a new location, these suggestions might all be relevant. In either case, use what makes the most sense in your situation.

Priority

Now what? We have some nice numbers and suggestions for how to match our backlog with these numbers, but what does that tell us? By themselves, not much, but if we put them together, we can use the two vectors to assess the Priority or ranking of the story. To do this, we simply multiply Urgency x Business Value and the product of these two numbers is the Priority. The result is a number ranging between 1 and 25.

Priority= Urgency x Business Value

Priority Ranges

Planning Poker Slideshare Download

I then break the values into ranges with a colour assigned to each range. For each range, I apply a ranking value as shown in the chart below. I use four ranges. Four seems to be enough to cover the necessary set of Actions and it has the advantage of fitting nicely into a chromatic scale from green to red. Experience shows that using five ranges causes people to obsess a bit more about their Business Value and Urgency ratings and slows down the process while not adding any real value. Five steps would also require an intermediate colour like an orangey-red or a greeny-yellow. Forcing people into colour discussions like this detracts from the ease and clarity this system tries to promote. Three steps are not enough – in particular because there is no way to accommodate the red or critical valuation. The particular selection of colours also maps to the mechanism I use for prioritizing bugs which I will discuss in an upcoming issue.

Planning Poker Slideshare Free

Agile Story Priority Ranges

Using the System

So now you have this nice way of ranking the importance of your stories and a nice colourful chart – how do you use it? 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.

Planning Poker Slideshare Pdf

The way I approach using the system is very simple. I leave a space in the upper right hand corner of my story cards. In that corner, I write the three numbers representing Urgency, Business Value and Priority; always in that order. When prioritizing a story, I do a quick assessment of Urgency and Business Value, and then simply multiply the two numbers together to get the Priority number. Then using a highlighter, I colour the Priority number according to the chart above. That’s it. It should take about 10-20 seconds per card. Some cards will require substantial debate amongst the stakeholders and that might be appropriate, but don’t waste your time on differentiating between green and yellow ratings. Instead focus on the red and orange, and then the obvious yellows. Once you’ve got them all rated, simply sort the cards according to their numeric value and you are done.

As you plan for each new sprint, review the ratings of each card in your backlog and change the ratings as appropriate. Some things will increase or decrease in their valuation, and there will most likely be new stories introduced, but again, do not spend much time at the green end of the spectrum. Instead stay focused on the high priority items

There you have it, a quick, easy to learn, easy to use system that will give you consistent, repeatable results.

I’m looking forward to your feedback. Please leave your comments below.

Michael

Tags: Agile, Agile Development, agile methodology, Agile Methods, Agile Project, architect, architecture, Backlog, index cards, priorities, priority, Project Management, repeatable results, scott ambler, Scrum, Software, Software Development, software products, sprint, Story Cards

I am an independent consultant who has been leading software teams, designing, building and delivering software for nearly three decades. It’s still as exciting and enjoyable for me today as at was when I wrote my very first Hello World program and saw it spring to life in front of me.

You May Also Like

Agile, Project Management, Risk Management, Software Development, Technology

Agile Program Risk Management