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.
What You Will Learn:
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:
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.
Interesting read. Good for agile projects.
Useful Article from Agile Prospective. Thanks.
Very Very Useful article……
Great article with detailed way of explanatio. Thanks alot!!
hi am somu i have done my diploma in electronic and telecommunication, and i have experience in mother board servicing for 3 years, and in excel base work i have 2 years experience currently i am working. but i want to go for better job please segues me which course i can go. i have two course in my mind, 1 is SQL, 2 JAVA so please segues me in my mail id.
please find my email id: ssomups@gmail.com
Dear Author,
Thanks for this article.
The estimation part is very clear however how to assign the Efforts for the user story. Assume that the 5 user stories have been estimated with 10 Poker points.
1. Is the team member allowed to give the estimate for this user story freely. Considering the experience of resource, for the same user story, different experience people will give different answers. In this case, how to validate which one is correct or do we need to really validate the Man days estimation given by the developer for the user story
Thanks in advance for your response.
Regards,
Harihara Prasath.
I understand the estimation is done in the story points – but how do I measure the story points? can you explain
how many Story points = how many Hours?
Hi Harihara
Thank you for your feedback on the article.
During Poker planning in Agile framework we provide estimates based on our similar past experiences, technical skills, and familiarity/domain knowledge of the Technical aspects of the task assigned. So needless to say, the effort is directly related to the skill level of the team resources.
As an example, an experienced resource can finish a given task in 1 day, however a new resource would take longer to finish the same task. So the estimate provided by both will vary accordingly.
There is no right or wrong in estimates. According to literal meaning of the word estimate, it means “roughly calculated or judged value”. So there is no validity check for the correctness for the estimate provided. As per my experience, once the team better understands their own capability and estimation process, the team gets better and more realistic in providing estimates.
It is however essential to know how many story point we can achieve as a team on an average. This allows us to plan project accordingly and prevent the situation where we promise more than we can deliver.
Hope this answers your question.
Thanks
Neha
Great article. It’s a good way and brings transparency in the process.
As mentioned in the conclusion it’s important to be prepared before such meetings.
Hi Farida
The determination of how many hours equal to 1 story point is an iterative and ever evolving process.
To establish a baseline you can assume a any value for story point. For example, you can set 1 story point = 4 hrs of effort. Based on that team can provide estimates. Lets say your team could deliver 20 story points in 10 working days. Therefore you can calculate the story point value based on your team velocity. We will assume an 7 hour work day for project related activity. Therefore total number of hours = 10 X 7 = 70 hours.
Now we can see that 20 story point translated to 70 hours which means 1 story point is 3.5 hours.
You can now consider this as a baseline for next sprint and recalculate after end of next sprint and so forth.
Hope this answers your question.
Thanks
Neha
Really very good, valued and clear article for estimation with Agile
Perfectly Explained, thanks a lot.
Hello Neha,
Excellent article, nicely written to the point. Specially I like your answers to 2 of the doubt by comentrators, thats so straight.
Now here is my queries
1. When u say Story point, is it user story or Function points within that US ?
2. In a estimation meeting, when we are saying that team has to decide “how man story points” I personally think this can not be measure of velocity of team instead most of the organisation (top management) take this as a meaure for productivity of team. Meaning to say, this calculation of Story point generally gets done by PM before Sprint planning meeting.
3. Additionally if you can explain what is appropriate way to calculate story point- as one of ur example (logo) says just because tester has to check it every place u increased story point. While for user perspective its single story. So what are criteria to be include while deciding story point- please justify ur answer.
Looking forward to hear from you.
Once again great article.
Hi,
Thanks for sharing the Agile process planning tools.
Agile Dev and QA is a very exciting approach. The collaboration and visibility provides a much richer and more rewarding experience for teams to develop great software products. Agile development and Quality Assurance are a lot more enjoyable than the waterfall approach, which requires lots more documentation and is less flexible by its nature. And when we start enjoying our work, then it’s amazing what we can achieve!
Thanks
Sumit
Hi Sachin
Thank you so much for your feedback. Glad you liked the article!
Regarding your queries, please find my answers below with my initials (NB):
1. When u say Story point, is it user story or Function points within that US ?
NB: In my article, I am referring to the story points for the entire user story
2. In a estimation meeting, when we are saying that team has to decide “how man story points” I personally think this can not be measure of velocity of team instead most of the organisation (top management) take this as a measure for productivity of team. Meaning to say, this calculation of Story point generally gets done by PM before Sprint planning meeting.
NB: Yes, I agree. The velocity needs to be calculated by PM after the sprint is closed. This can be done periodically to establish an average baseline which can be used for future sprint planning meetings.
3. Additionally if you can explain what is appropriate way to calculate story point- as one of ur example (logo) says just because tester has to check it every place u increased story point. While for user perspective its single story. So what are criteria to be include while deciding story point- please justify ur answer.
NB: The criteria in this case would be the uncertainty involved and the overall effort required to complete the task . If the logo would be updated at 1 place, developer would need to make changes in 1 place and QA can be sure that if the logo shows as changed in one place, it would surely show as changed on other pages. However if the Website is designed in such a way that the logo change needs to be done on each page individually,it increases the overall effort (development and QA) that will be spent on this task. Also there will be uncertainty about the outcome- that if the logo shows in one page, it may or may not show in all pages.
Thanks again for your positive feedback.
Thanks
Neha
nice
Hi Sumit
I agree. The beauty of Agile methodology lies in collaboration.
Thanks
Neha
Hai,
Awesome Article and i would like estimate the effort in agile using story points in agile in my research. i would like to get some datasets on user stories or story points with relevant velocity. please suggest me where should i get it. I will be more honored if provides
Hi @Prasad
Glad you liked the article.
I am not aware of sample or research data sets that are publicly available for the user stories, their story points and corresponding velocity. Perhaps our readers would have some input for this?
Hi Neha, I want to recommend another online planning poker tool pokrex. It’s has clean UI which is easy to use, support flexible point schemes and JIRA integration.
hi Alex S
Thank you for sharing this helpful information. I would explore this tool for sure :)!
Thanks
Neha
Hi Neha,
Really liked your description and we all read this in our scrum-team to remind us of the essence, even though we have been using this for more than a year now 😉 Most of the time we are lucky enough to all be present at the same time, but when we work remotely we end up needing a tool for estimations.
After trying out a couple, we struggled with the time needed to set it up for all the members before we could actually start the planning. So we built our own tool – nothing fancy – but simple and especially allows for a quick set-up. Maybe it will help others besides ourselves 😉
Big thanks for the article,
Paul
hi @Paul
Thank you for the feedback. I am glad you liked the article and that your team found the information in here helpful 🙂 !
Thanks
Neha
Hi Neha ,Thanks for the given information can you explain ,what are the circumstances where we provide story points morethan 8.