Planning Poker

Case study
• 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
Case study
• 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
• Assumptions:
• 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.
Planning Poker
• 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.
Planning Poker
• 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.
Planning Poker
• 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