How to Make Agile Estimation Process Easy With Planning Poker

An 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; we can also gauge the ripeness of a fruit by its aroma.

In today’s article, we will learn about Planning Poker also known as Scrum Poker Cards, an agile estimation, and planning technique, which is a very popular, easy, and simple technique in current days.

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

Tim, Bob, and John who want to drive to a Technical Conference after work. The venue is 60 km away and has a hilly terrain. Tim, Bob, and John discuss the travel plan over lunchtime. 

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 on 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 will take for each one of them to drive to the Technical Conference based on their past 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 requirement 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 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 software development life cycle.

Understanding Units of Estimation

The units of estimation can be in hours, days or story points. Estimates in 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.  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. Higher the story point value, 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. Therefore 1 story point ? 1 hour.

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 techniques makes the use of cards to provide estimates. We will discuss

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

When Is Planning Poker Done?

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

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

For example, based on the previous velocity and performance of the team, the Project Manager is aware that the team is capable of delivering 20 story points in 2 weeks. If during the planning poker session, total estimate of the pre-selected user stories exceeds 20 story point, 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 us conduct a mock planning poker session to get a better idea of the process.

To conduct the planning poker session you would require several copies of deck of scrum planning cards. It is not necessary to have paper based cards.  There are several online apps like Scrum Poker (android) or Scrum Poker planning (IOS), etc. that 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.

Below figure shows a deck of Poker planning cards:

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

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

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

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

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

We will assume that the facilitator is Tia, 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 the potential user stories to be included in 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 ask clarifications, discuss briefly the impact areas, the development methodology, etc.

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

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

Step #6: Tia provides an overview of Requirement 2. All chose 1 story point as an estimate, the consensus is reached, team moves on to 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 is not reached, Tony and Gavin are asked to justify their choice. Tony says that since University logo is displayed from a single location in every web page, they only need to update the logo at that one location and thinks that 1 story point is a sufficient estimate for development and testing both.

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, the testing would need to be done for multiple browsers. So according to Gavin, 2 story points is a realistic estimate for development and testing.

Step #8: Tia calls for the revaluation of estimates. Now, Maria, Tony, and Gavin are in agreement 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.  Project Manager/Project Analyst then formally create a new sprint and schedule the start date and end date of the sprint.

Summary Of Steps

(Click to enlarge image)

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 in order 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 an estimate attached to the task will be higher.

#2. Planning poker meeting is a time bound activity and its purpose is to come together as a team and provide estimates. The focus should be to provide estimated 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 actually 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 all global locations.

#4. Remember to have fun!

[image source]

Conclusion

• Planning Poker Estimation works really well in agile methodology.
• This technique is scalable and estimates are based on team velocity
• Planning Poker is also very successful due to the fact that 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 using Planning poker technique for Agile estimation and planning.