Effective estimation is one of the toughest challenges software developers face in their jobs. Regardless of team size, they need to define, estimate, and distribute work throughout a team. As teams get larger, it becomes even more important to build good habits around planning and estimating work. Lack of planning and estimating reduce confidence in a program, breaks down relationships between the team and the business, and makes development harder on everyone.

• The agile scrum Planning Poker Cards can be used as a method for grading tasks. Within this method you can plan tasks using Fibonacci numbers or T-shirt sizes. A fun and simple way to come to a goal oriented planning with your team. Want to know more about planning poker? Read our blog: Planning poker: play the game! This set is good for 4 team.
• Planning poker (also called Scrum poker) helps agile teams estimate the time and effort needed to complete each initiative on their product backlog. The name from this gamified technique is planning poker because participants use physical cards.
• The planning poker set of numbers are normally distributed such that the gaps between the numbers keeps getting bigger. I believe this is meant to discourage people from arguing over whether a user story is a 16 or a 17, if it's bigger than a 13 then just make it a 20.

Best Scrum Software Every Project Needs

A powerful scrum software that supports scrum project management. It features scrum tools like user story map, product backlog management, sprint backlog management, task management, daily scrum meeting, sprint planning tool, sprint review tool, sprint retrospective tool, burndown, impediment, stakeholder and team management.

Set up your planning poker session in seconds. Online app to support you and your team with story point estimations. Set up your planning poker in seconds and start estimating story points in scrum poker now. 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 Accuracy of Group vs. Individual Estimation

According to some study on the accuracy of estimation of effort between individual and group in an experiment for a software project. 20 software professionals from the same company individually estimated the work effort required to implement the same software development project. The participants had different background and roles and the software project had previously been implemented. After that, they formed five groups. Each group agreed on one estimation by discussing and combining of the knowledge among them.

Result – The estimates based on group discussions were more accurate than the individual estimates.

What is Planning Poker?

Planning poker (also known as Scrum poker) is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development.

Steps for Planning Poker

1. To start a poker planning session, the product owner or customer reads an agile user story or describes a feature to the estimators.
   For example:
   “Customer logs in to the reservation system”
   “Customer enters search criteria for a hotel reservation”
2. Team members of the group make estimates by playing numbered cards face-down to the table without revealing their estimate (Fibonacci values: 1,2,3,5,8,13,20,40)
3. Cards are simultaneously displayed
4. The estimates are then discussed and high and low estimates are explained
5. Repeat as needed until estimates converge

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

An estimate is nothing more than a well educated guess. We use all the knowledge and experience at hand to make a guess about the amount of time it is going to take. So instead of looking at every new work item separately, why not compare it to previously finished work items? It’s easier for humans to relate to similar items than to guess the actual size of things anyway.

For example, is it closer to this really small thing? Or is it more like this normal sized item? Or is it really huge like that one piece of work we finished last month? Doing relative estimates will not only reduce the amount of time spent on estimating work, it will also heavily increase the accuracy of the estimates.

Our brain is not capable of doing absolute estimates; we always put that new thing that we need to estimate in relationship to things we already know.

Fibonacci sequence and Planning Poker

Planning Poker uses of the Fibonacci sequence to assign a point value to a feature or user story. The Fibonacci sequence is a mathematical series of numbers that was introduced in the 13th century and used to explain certain formative aspects of nature, such as the branching of trees. The series is generated by adding the two previous numbers together to get the next value in the sequence: 0, 1, 1, 2, 3, 5, 8, 13, 21, and so on.

For agile estimation purposes, some of the numbers have been changed, resulting in the following series: 1, 2, 3, 5, 8, 13, 20, 40, 100 as shown in the Figure below:

The Interpretation of the point assigned to a poker card is listed in the table below:

Point vs Hour Value in Estimation

So why use story points instead of time values? Story pointing allows the team to focus on the complexity and time involved in delivering a piece of work. The team compares the new work against work they’ve already done. They compare the complexity of the new assignment against past challenges and rank the difficulty as well as the time required.

For example, we don’t often account for “the cost of doing business.” Meetings, email, code reviews, etc. with time values. But in reality, all these are necessary practices throughout in our daily life, but don’t actually count as “work.” Story points isolate the software development work from the associated logistic work items, so estimates using point based should more consistent than hour base approach.

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.

Scrum Planning Poker App

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

Estimating controversy

Scrum Planning Poker Numbers How To Play

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