Task estimation is a critical challenge that software developers constantly face in their jobs. No matter what team size is, they need to estimate and distribute work throughout their teams.

It’s rather beneficial to evolve good habits around planning and estimating work. If you have weak planning and estimating processes, you loosen relationships between the team and the business, decrease confidence and make development harder.

However, if you don’t like to evaluate tasks “by eye” and want to get transparent and accurate results, try Planning Poker. Here we will briefly describe how to do it.

What is Planning Poker in Agile?

Many Agile teams use the Planning Poker concept for their Agile estimation. What does this exactly mean? 

Planning poker in software development is a gamified consensus-based method for estimating that is predominantly used to estimate effort or relative size of development goals. You may also find it in some sources as Scrum poker.  

There are many other interesting estimation techniques (Bucket System, T-Shirt Sizes, Affinity Mapping, Dot Voting, and more), however, estimation with Planning Poker is one of the most popular solutions.

Sometimes it may not work because features are too large, there is not enough detailed information on the items to be estimated or there is not enough time to do estimation on the full backlog. However, in most cases, the technique looks rather powerful.

What are the roots of the technique?

Trying to find the origins of Planning Poker, it’s worth defining the following milestones:

  • In the 1970s, Barry Boehm proposed the Wideband Delphi concept – the forerunner of Planning Poker.
  • In 2002, the article by James Grenningthe with the current form of Planning Poker was published.
  • In 2005, the technique was popularized in the Scrum community.

How Does It Work?

All the people involved use numbered Playing Poker cards for estimating the items. As voting is performed anonymously, it may lead to many discussions when there are large differences. The voting process is repeated until the entire team reached a consensus about the clear estimation. 

The best way to apply Planning Poker is the case when you have to estimate a relatively small number of items in a small team (for example, 10 items with 6-8 people). 

So, the process bases on consensus. It actually works on the use of the Fibonacci sequence for assigning a point value to an item or feature.

Fibonacci sequence is a mathematical series of numbers. This concept with century-old history is now widely used to explain particular formative aspects of nature. According to the algorithm, you add the two previous numbers together to get the next value in the sequence: 0, 1, 1, 2, 3, 5, 8, 13, 20, and so on.

Product owners should read a particular user story or describe a feature to the estimators before starting the Planning Poker process.

Every estimator has a deck of cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100 (the sequence that is recommended). The values represent the number of story points that the team estimates (there can also be ideal days or other units).

Here are the steps of Planning Poker:

  • Team members meet in the same place with the customer or a Product Owner. 
  • They get a set of cards.
  • A Product Owner shows the item for estimation and everyone discusses it.
  • All team players choose a card that represents their estimate and the chosen cards are revealed at the same time.
  • If all participants have selected the same card, that point value is the estimate. If the cards are not the same – everybody discusses the estimate. A team member who has selected the lowest value explains why he/she selected the value. A person who has selected the highest value explains why he/she selected it.
  • Such selection happens until estimates converge. The 2-minute timer can be used to timebox the conversation.

All about the special cards

Applying this technique, you’ll face some special cards:

  • Zero card that means that this story is already done or it is about just a few minutes of work.
  • Question mark card means that you have no idea at all. If this card is used too often, the team needs to discuss the stories more.
  • Coffee cup card means that you are too tired to think and need to have a break.

What are the expected benefits?

  • This informal and structured format of planning keeps things moving forward and avoids the estimating meeting getting bogged down in countless discussions.
  • Planning Poker allows leveraging the knowledge of all team members. It is rather important as in less-structured meeting formats, the more communicable team players often shut out the quiet people.
  • The discussion that follows the revealing of initial estimates is a productive way to combine insights about the user stories and implementation risks.
  • Planning Poker motivates individuals to think about the items of the product backlog, proposing some valuable ideas to reach consensus. 
  • The activity provides a better understanding and resolves queries as the people in the team share their inputs on product backlog items.

What about pitfalls?

  • Some people insist that Planning Poker is not an estimating tool but the tool that just can help teams to size the effort needed to complete a user story (if properly applied).
  • Often Scrum Masters guide the team to the desired answer rather than allow people to arrive at their answer based on conversation.
  • Sometimes Planning Poker becomes a source of dread during planning, however, it only should introduce an element of fun.
  • Additionally, it can be a bad practice of adding points based on the domain. It is when software development guys agree on how many points to design the story and then the QA specialists add the points needed to complete testing.

Some quick tips

  • It’s better to strive to ensure that the complexity of tasks does not exceed one day.
  • You’d better plan in the way to ensure the team has a supply of tasks for nome more than 1-2 days. Your team members will remember all the details of the discussion of each specific task. 
  • If your task is performed 2 days longer, it must be taken out again for planning and discussion.
  • The format of Planning Poker will suit developers, admins, analysts, and other teams. It helps them to better understand the tasks and define solutions at the stage of setting.

How do you evaluate tasks, the complexity and the time of their completion? Feel free to comment and share your experience.