Planning Poker or Scrum Poker Agile Estimation Technique

An in-depth analysis of Planning Poker Technique with examples. Planning Poker Technique – commonly known as Scrum Poker Cards is a simple and easy agile estimation process technique:

The art of estimation is known to all. We estimate every day in our lives. Most of us can estimate the weight of the vegetables just by holding them and even gauge the ripeness of a fruit by its aroma.

For a real-life example of estimation let’s take a scenario of 3 friends: 

Tim, Bob, and John want to drive to a Technical Conference after work. The venue is 60 km away and has hilly terrain. Tim, Bob, and John discussed their travel plans over lunchtime. 

Planning Poker Technique: Simple Guide

Bob says, “I have been to this conference last year as well. I know the way and it will take 2 hours to drive there”.

Tim says, “I am a new driver, and I have never been to that area before. If I drive, it will take 4 hours.” 

John says, “I am okay with driving in a hilly area but I have not been there before. So it might take me 3 hours to drive us all there”

This seems like a regular conversation, but these friends just estimated how long it would take for each one of them to drive to the Technical Conference based on their experience, their driving skills, and familiarity with the terrain.

Similarly, in Software development, we provide estimates based on our similar past experiences, technical skills, and familiarity/domain knowledge of the Technical aspects of the task assigned.

Why Do We Need to Estimate

The software project delivery schedule is driven by business needs. In order for the team to commit to the deadlines, it is important for the team to come together and provide a realistic estimate.

Early on in the project, the requirements may not be well defined, the detailed development methodology may not be outlined, dependencies may not have been identified, etc. Still, it is important to establish a high-level estimate so that the project can be planned accordingly.

For example, if the high-level estimate is more than what the team can achieve in a given duration, decisions can be made if an additional resource needs to be acquired, deadlines need to be extended, etc.

Thus, estimation is a very crucial step in the software development life cycle.

Understanding Units of Estimation

The units of estimation can be in hours, days, or story points. Estimates of hours and days are easy to understand and relate to. The concept of story points is more abstract.

Story points are used as a measure of complexity and unknowns associated with a task.  The story point value is calculated according to a calculated baseline. This baseline is established by the team itself based on the velocity of the team in past projects. The higher the story point value, the more effort is required to implement a particular task.

It is, however, important to understand that story points do not equate to hours, so it is difficult to compare story points and effort estimation in hours.

What is Planning Poker or Scrum Poker

As defined in Wikipedia:

“Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development”

The word “Poker” reminds everyone about the Poker card game, and needless to say, this estimation technique makes use of cards to provide estimates.

We will discuss the cards and how a planning poker session is carried out in the subsequent sections of the article.

When is Planning Poker Done

Planning Poker is an estimation technique and, like all estimated providing sessions, should be held before the iteration/sprint starts.

User stories can be picked up from backlog issues and pre-selected before the Planning poker meeting. Based on the estimates provided for the user stories, a decision can be made regarding the stories to include in each iteration.

To give an example, based on the team’s previous velocity and performance, the Project Manager is aware that the team is capable of delivering 20 story points in 2 weeks. If during the planning poker session, the total estimate of the pre-selected user stories exceeds 20 story points, then the Project Manager will make decisions regarding which user stories to include and/or omit in the next iteration so that the team can successfully deliver the committed user stories on time.

Conducting Planning Poker Session

Let’s conduct a mock planning poker session to get a better idea of the process.

To conduct a planning poker session, you would require several copies of the deck of scrum planning cards. It is not necessary to have paper-based cards.  Several online apps like Scrum Poker (android) or Scrum Poker Planning (IOS), etc. can be used.

The cards will have common estimates on them e.g. 0, 0.5,1, 2, 3, 5, 8, 13, 20, etc. This sequencing will look familiar to most of the readers and is the Fibonacci series.

Some other optional cards are: ?- for indicating that the estimator is uncertain, Infinity symbol- to indicate that the task cannot be completed, and Coffee cup card – to indicate that the estimator needs to take a break.

The figure below shows a deck of Poker planning cards:

If you wish, you may also use a timer device to track and limit the time spent on each discussion

For this poker planning session, consider a web-based university registration application. Following are the stories from the backlog that are to be implemented in the upcoming sprint:

User Story 1: As a user, I should not be able to register without providing my cell phone number

Description: Make the cell phone field mandatory. The user will get the error message “Cell Phone number is Mandatory” message if the field is left empty. There should be a “Close” button on this pop-up error message. The UI of the dialog box and font size and style of the error message text should be the same as other popup messages in the form. This message will be triggered when a user tries to save the application.

User Story 2: As a user, I should not be able to register without providing my cell phone number in the proper format

Description: Add validation for cell number (should now be in format 111-111-1111). The user will get “The format of cell phone number should be 111-111-1111” if the format is incorrect. There should be a ‘Close’ button on this pop-up error message. The UI of the dialog box and font size and style of the error message text should be the same as other pop-up messages in the form. This validation will be triggered when the user tries to save the application

Task 3: Change the University Logo to the new Logo on all 75 pages of the web application

We will assume that the facilitator will be Tia, the Product Analyst for the project. The estimators are Tony (Developer), Maria (UI Designer), and Gavin (Tester). Jose, the Project Manager, will be present in the meeting as well but will not participate in the estimation.

Step #1: Tia schedules a planning poker session and circulates potential user stories to be included in the next sprint with the team.

Step #2: All the participants attend the meeting.  When the meeting starts, Tia hands out the deck of cards to each estimator or each estimator opens the planning poker card app on their smartphones.

Step #3: Tia gives an overview of User Story 1. Estimators will ask for clarification and briefly discuss the impact areas, development methodology, etc.

Step #4: When asked by Tia, each estimator calls their number. Maria, Tony, and Gavin all chose 2 story points as an estimate.

Step #5: Since consensus is reached, the team is moving on to the next requirement.

Step #6: Tia provides an overview of Requirement 2. All chose 1 story point as an estimate, the consensus was reached and the team moved on to the next requirement.

Step #7: Tia provides an overview of Task 3. Maria and Tony chose 1 and Gavin chose 2 story points as an estimate. Since consensus has not been reached, Tony and Gavin have been asked to justify their choice. Tony says that since the University logo is displayed from a single location on every web page, they only need to update the logo at that one location and think that 1 story point is a sufficient estimate for both development and testing.

Gavin, on the other hand, argues that although the logo location is centralized, all the web pages use different style sheets, the tester would need to navigate to each web page and check if the logo is displayed correctly (should not appear cut off, should not appear stretched, etc.).

Also, testing would need to be done for multiple browsers. So according to Gavin, 2 story points are a realistic estimate for development and testing.

Step #8: Tia calls for the revaluation of estimates. Maria, Tony, and Gavin agree and chose 2 story points as an estimate.

All the user stories are now estimated, with the next sprint total story point value as 2+1+2=5 story points.  The Project Manager/Project Analyst will then formally create a new sprint and schedule the start date and end date of the sprint.

Summary of Steps

Planning Poker Online Tools:

1. PlanningPoker
2. Plan ITPoker
3. Pointing poker
4. Agile poker for JIRA
5. Sprint Poker
6. Agile@Hand

Some Useful Tips

#1) The estimators should come prepared and go through the requirements beforehand. This can be done in Backlog Grooming sessions. Being prepared is essential because the estimates need to be provided based on the understanding of requirements.

For example, to provide an accurate estimate, the developer needs to be clear about the methodology he will be following to implement the requirements. If there are some unknowns, or the task is high complexity, the story point and estimate attached to the task will be higher.

#2) Planning poker meetings is a time-bound activity and its purpose is to come together as a team and provide estimates. The focus should be to provide estimates based on the teams’ previous performances (or velocity). This meeting should not be confused with other meetings like Daily Scrum, Backlog Grooming, or Retrospective meetings.

#3) Estimates should be provided by the people who will work on the project. With teams that are located at different locations geographically, the actual people working on the project need to collaborate and provide estimates. The meeting can be held online to facilitate teams from any location in the world.

#4) Remember to have fun!

[image source]

Conclusion

• Planning Poker Estimation works well with agile methodology.
• This technique is scalable and estimates are based on team velocity
• Planning Poker is also very successful because we receive estimates directly from people who are going to work on the task and so is more realistic.
• If the Project Manager provides the estimates himself, without consulting the team or finalizing the technical details, it may essentially put the project at risk due to assumptions made, details overlooked, etc.
• More and more companies are now transitioning towards Agile and using such non-traditional estimation techniques.

Estimation is an essential part of Project planning. The approach for estimating should be consistent, flexible, should be scalable, and should work well for smaller tasks and user stories alike. Also, it should not consume a lot of team time and resources.

The last thing you need is an estimation task for Estimating!

About the author: This useful article is written by Neha B. She is currently working as a Quality Assurance Manager and specialize in leading and managing In-house and Offshore QA teams.

Let us know if you have any queries/feedback about using Planning poker techniques for Agile estimation and planning. We would love to hear from you.