Agile Concepts: Estimating and Planning Poker

Planning Poker® in Scrum brings together multiple expert opinions for the agile estimation of a project. In this type of agile planning, we include everyone from programmers, testers and database engineers to analysts, user interaction designers and more. Because these team members represent all. Planning Poker is a consensus-based technique for estimation, mostly used to estimate effort or relative size of development goals in software product development. Planning Poker is done with story points, ideal days, or any other estimating units. The Scrum Master, Product Owner, and the development team participate in Planning Poker activity. PlanITpoker is a cool on-line planning poker app that helps Agile project teams estimate projects easily. With a one click signup and always free, Try it today! PlanITpoker: Online Scrum planning poker for Agile project teams. The estimation of the story points depends on the type of estimation used by the team such as t-shirt sizing or planning poker. Uncertainty and Risks. The story points are affected by the amount of uncertainty and risks that the Product Backlog item contains. The pitfalls noted here are based on my personal experience coaching teams using Scrum with Planning Poker for over a decade. Often time the trouble starts when a well-meaning ScrumMaster experiments with the process of Planning Poker before they have personal experience in how the tool should be used.

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

Scrum Planning Poker App

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.

Agile Planning Poker Playing online, free

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).

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.

Before you start debating story points versus no estimates, let’s examine what can go wrong when a team uses Planning Poker® with Story Points to estimate their work. The first misnomer is that Planning Poker is not an estimating tool. It is a tool, that when properly applied can help a team size the effort needed to complete a user story. Let’s begin using the term sizing for stories instead of estimating.

The pitfalls noted here are based on my personal experience coaching teams using Scrum with Planning Poker for over a decade. Often time the trouble starts when a well-meaning ScrumMaster experiments with the process of Planning Poker before they have personal experience in how the tool should be used. ScrumMasters often guide the team to the desired answer rather than let the team arrive at their answer based on conversation and understanding of the work. Even worse, I have witnessed several ScrumMasters declaring the story point value once the story is read.

Agile Planning Poker

Planning Poker should introduce an element of fun and not become a source of dread during planning. Another pitfall of Planning Poker occurs when team members are allowed to select their size one at a time. This behavior encourages intimidation by more experienced team members and discourages others to think independently.

One of the worst experience you can have as a team is trying to size too many stories at one time. If your team typically completes 10 stories a sprint, why would you size 20 or more stories in sprint planning? Sizing too many stories leads to fatigue and waste.

Scrum Planning Poker Points Leaders

Yet another pitfall of Planning Poker occurs when teams are expected to size stories that lack appropriate acceptance criteria. A long list of acceptance criteria can indicate a story that is too large to fit in a sprint.

Scrum Planning Poker Points Games

Then there is the bad practice of adding points based on the domain when developers agree on how many points to design and code the story and then the testers add the points needed to complete testing.

Given the opportunity for challenges using Planning Poker, it’s not surprising to learn that many people have had poor experiences using this technique. Follow me, Linda Cook, on www.projectcooks.com to learn more about good techniques for use Scrum, including Planning Poker.