Scrum Planning Poker Numbers

Scrum Planning Poker steps By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates. Agile Estimation – Relative vs Absolute.

Planning Poker is a simple and fun way to estimate a list of Backlog Items. It is an integral part of VivifyScrum - project management tool and estimating tool in one. Participants in Planning Poker. A ScrumMaster facilitates Planning Poker and helps Development Teams makes decisions, while a Product Owner clarifies questions raised by the Development Teams. About the Author: The author, Suresh Konduru, is a Certified Scrum Trainer (CST) certified by Scrum Alliance, and is based out of Hyderabad, India.

Agile Concepts: Estimating and Planning Poker

Most Agile frameworks include some form of estimation*. Estimating the relative size of stories in terms of effort/time can help a team to decide how many of the highest priority stories from the product backlog can be taken on in a single sprint.

Estimating is also used to measure the velocity of a team (the amount of work it gets through per sprint), helping the business to forecast and budget product development.

Estimating using story points

The most common way of estimating the size of user stories in Scrum is by allocating story points. Story points are just numbers drawn from a pool of numbers of a set size e.g. a story could have 1, 2, 3, 5, 8, 13, 20, 40 or 100 story points.

The reason for using a Fibonacci-like sequence of numbers is to encourage stories to be estimated relatively (e.g. that story looks like it requires about twice the effort for a story we’ve already agreed is a 2 so it’s probably a 5) and to emphasise that the larger the story, the more uncertain the estimate.

Who estimates?

A Scrum team will estimate story points during backlog refinement or perhaps as part of a dedicated session. It’s essential that the whole team is involved in the process of estimation so that the estimates are made by the people who will actually be doing the work and are therefore as accurate as possible.

When a story is ready for estimation – i.e. when it is small enough to fit within a single sprint and when the acceptance criteria have been agreed by the scrum team – the team then discusses its relative size and reaches consensus over how many story points of effort it requires.

Stories may be estimated before these criteria are met but should be revisited.

The most common way to do this is Scrum is by playing planning poker.

Planning poker

In planning poker each member of the team gets a set of playing cards with the allowable story points printed on the front as well as extra cards for don’t know (?), infinity or, sometimes, to indicate it’s time for a coffee break.

Once the story is ready to be estimated, there is a round of voting. At the same time, all team members hold up the card which corresponds to their estimate.

If all the team members agree then the story is given that number of points and the team moves on.

If there are discrepancies then the ScrumMaster facilitates a discussion where team members can further explore what’s required, investigate acceptance criteria further etc. There is then another round of voting and this repeats until consensus is achieved.

It’s particularly important to discuss the lowest and highest estimates from the team, this often leads to clarifications with the Product Owner and an updated set of assumptions for the estimate (which should be captured).

Scrum Planning Poker App

Estimating controversy

*Estimating is a hot button topic in Agile right now. Some argue that estimating is a process of the kind that Agile should be pushing to the background in favour of individuals and interactions and also a form of contracting which should be de-emphasised in favour of customer collaboration. They argue that estimating how long it will take to deliver a product – the development of which will be inherently unpredictable – based on guesswork is a useless activity which fits the incremental model better than it fits a purely iterative one (see Agile vs Waterfall).

The reality is in real world scenarios it is almost always critically important to have ability to forward plan. Story points and velocity give a pragmatic way to do this and often on the projects where Scrum is used there is a good understanding of the type of work being done and the estimates are of a good standard.

Using techniques like triangulation and reference stories aid the process.

Whether you think it’s a futile box-ticking exercise or a useful way for businesses to plan product development, it’s important as practitioners that we understand how to estimate effectively.

Story points and velocity are probably the most well known tools for estimation in Agile environments. They are the basis for predictability with Scrum. To begin with, we should be clear on what a story point is. Most people reading this will have heard at least one definition, and probably more than one. I’m going to go with the king of planning poker, Mike Cohn.

Mike defines story points in the following way :

“They are a unit of measure for expressing the overall size of a user story or feature. They tell us how big a story is, relative to others, either in terms of size or complexity”

With that understanding, let’s set the scene. We are in our sprint planning meeting. The Development Team (DT) are sat alongside the Product Owner (PO) who has bought along their prioritised product backlog, and the Scrum Master (SM) is about to kick the session off by defining the desired outcome of the meeting. The desired outcome of the sprint planning meeting may be as follows:

• There is an agreed sprint backlog
• The DT have reached a consensus on the size and complexity of each story in the sprint backlog (in story points)
• The DT and the PO have a shared understanding of each story in the sprint backlog
• The SM has ensured that the team have not planned too much work by checking the story points planned against a known velocity

As the session goes on, the product owner will talk through each story on the the product backlog. The team will ask questions of the PO and of each other in order to gain a shared understanding of the story. Once they think they have this, the SM will provide them with planning poker cards and the act of sizing will begin.

The DT will be a group made up of people with different levels of experience, knowledge and skill. Sizing with planning poker helps to ensure that everyone’s voice is heard, and that all opinions are taken into account, not just those of the team lead or architect. In this way it may be possible for anyone in the DT to pick up any story during the sprint.

To begin, the DT find a benchmark to relatively size each new story against. In sprint one, the SM may ask them to find an average size story on the product backlog. In later sprints, perhaps more appropriately, they may look back at stories already completed and find one with a size they now know to be accurate.

The SM will ask the DT to decide individually the size of the story being discussed, and the DT will hold up the card representing that number of story points. They will do so simultaneously so as not to be influenced by any other member of the team. If the DT don’t have consensus on the size of the story, further important discussion will ensue, facilitated by the SM. It may require another round or two of poker, but eventually consensus will be reached on size as members of the DT persuade each other with constructive reasoning.

This process will be repeated with the next story on the product backlog, and then the next, and so on until the DT believe they have enough work to fill the sprint. Now the SM will check to see how many story points have been planned. If this is the first sprint the DT have undertaken they will probably agree to start with what they have. If not, the SM will compare the number of points planned against team velocity.

What is our team velocity?

Velocity = total story points / no. of sprints

For example

Scrum Planning Poker Numbers Free

Last 5 sprints completed points were:

30, 40, 50, 60, 70 = 250 points / 5 sprints = velocity of 50 points

Scrum Planning Poker Numbers Template

Now that we have our velocity, we may want to turn that into a time estimate.

How big is my project?

Total estimate (points) / velocity = number of sprints

e.g. 500 story points for project / 50 points = 10 sprints

How long will it take?

Number of sprints x length of sprint (weeks)

Scrum Planning Poker Numbers And Meanings

e.g. 2 weeks sprints = 10 sprints x 2 weeks = 20 weeks

Of course, this still requires you to have broken down the entire project into stories and to have sized all of them. This is a significant up front task.

Agile Planning Poker

The alternative is to try and keep projects relatively small, and to plan at a number of different levels. At a project level, use ranges for the length of the project leaving more granular estimates for each sprint as you plan them. Perhaps you can break a project into rough sprint blocks (i.e. this section of the project is 1-3 sprints) and use this to calculate your range. Ensure that you provide your project estimate with a level of confidence attached. As you learn more from the granular process and as you complete work, you can begin to narrow the range for the overall project estimate and provide a greater level of confidence.

Agile Planning Poker Playing online, free

Photo credit (homepage): Mountain Goat Softare