(see also: Agile Moment: Equating Story Points to Time, Scrum Effort Estimation, Practical Guide Story Points Estimation, How Story Points relate to hours, Story Points vs. Task Hours, Planning Poker)
Overview
Estimating story points for user stories that implement features on the Scrum teams product roadmap / product backlog is a critical planning exercise. All Scrum teams should utilize planning methods to estimate engineering efforts for future work. There are many possible methods available to estimate effort. However, for teams that are using Agile frameworks like Scrum, a proven, highly effective method of choice is Planning Poker. The overall goal of planning poker is to establish a clear consensus on an estimate for a given scope of work or user story.
Normalization of a relative estimating technique is absolutely critical for a team to reach a high-performance state. This also directly impacts an organization’s ability to perform capacity planning and management in scaled Agile applications.
How to estimate Story Points for a user story using Planning Poker
As with any way of working there are other potential successful methods for getting the same results. The following are prescriptive steps that can be taken in order to effect a positive and successful outcome for estimating engineering effort. Your mileage may vary. The process steps below assume a working Scrum team is established.
PREPARATION
It is important that your team has already met and conducted a few planning and backlog grooming sessions prior to performing an estimation operation. YMMV depending on the size and scope of your organization and unique attributes of the project. Quite often, the responsibility for Product Ownership and the person whom will actually perform the role are different people. This is not ideal, but it is a reality for many organizations. In my experience the process of creating stories from themes / epics should cause the stories to be documented fairly well. If a Product Owner is unable to participate in the planning poker sessions and a question comes up that blocks estimation, just table the story. Get the answer(s) offline then push the story back into the next PP session.
STEP 1 – READ A FEW OF THE SHORT REFERENCE ARTICLES LINKED ABOVE
There is no reason to re-invent the wheel. There are hundreds of articles on the Internet covering various scientific / empirical / opinion based methods for accomplishing story point based estimation. Obtaining a good foundational understanding of the concept is critical before you continue to the next step. First we learn, then we practice.
STEP 2 – ORGANIZE A PLANNING POKER MEETING WITH YOUR TEAM
Planning Poker is a social exercise that is structured with the intent to draw out risks, requirements analysis, and discussion of a scope of work(s). Planning poker is also a collaborative engagement of experts analyzing and determining relative effort for specific tasks based on historical performance for a given Scrum team. Planning poker benefits the team and accurate estimation of engineering efforts through collaboration, discussion, defense, and debate (CD3). It is a lightweight, agile exercise not meant to consume large amounts of time. In fact, in general planning poker for a particular user story should take no longer than 3-5 minutes. Each round of discussion on a user story should be no longer than 2 minutes time boxed.
When scheduling and planning your meeting you should determine which user stories (count) will be estimated and send that list out to the Scrum team prior to the meeting for review. Schedule the meeting for an amount of time equal to 5 minutes per user story to be reviewed plus 5-8 minutes of pre and post operational discussion.
Planning a meeting for remote teams is only slightly different in that you will be holding the meeting using your choice of video conferencing software (I recommend video to maximize remote communication potential). It is certainly more efficient for the agenda to hold a meeting in person but this is not always possible in today’s multinational and multicultural business environments.
STEP 3 – PLANNING POKER STORY POINT DECK
The first step in conducting a planning poker session is to establish a standardized set (deck / list /et cetera) of story point cards (like playing cards). There are unlimited possibilities for your particular Scrum team. Some teams use shirt sizes like S, M, L, XL and others use point decks from 0 to 100 or infinity. The critical element to ensure in your planning poker deck is that it includes a sequence of “sizes” similar (not exactly) in relationship to the Fibonacci Sequence. The key intent is relativism (context of numbers, not religopoliti), not absolutism in numbers or scale. Lastly, make sure your team uses the same story point cards for all planning poker sessions.
If you read the reference articles above you will know that these numbers do not equate to hours, weeks or any amount of time. The amount of time represented will be derived over time related to a particular Scrum team. After working together for a few months the story points and sizing effort for a scrum team will come out of the process and collaboration (historical sizing and expert judgment). Only after maturity is reached on a team may the story points be mapped and analyzed to determine a normalized mean amount of time for a size “4” user story. Even then, the metric would only have meaning (value) on that particular Scrum team. However, this is impossible to determine on a new scrum team and also nearly impossible to ascertain on a scrum team with poor planning and compliance discipline to the process.
NOTES:
- A size “0” card means the effort has already been accomplished
- A size “100” card means that further discussion and work needs to be done on the user story to refine it and associated feature(s)
- An infinity card means that is it impossible to estimate the effort
- The coffee card means I need a break
STEP 4 – BEGIN A PLANNING POKER SESSION
The Scrum master and/or the team lead should begin the process of reviewing the selected user stories with the team. A brief (60 seconds) introduction to the set of user stories to be reviewed should ramp the team up in preparation for the estimations. During this introduction, remind the team of the basic principles of planning poker.
STEP 5 – CHOOSE A USER STORY
The team lead (engineering lead or scrum master) should choose the first user story on which the team will estimate engineering effort using planning poker. Share the user story details with the team. This is important so each team member is able to see the scope of work, acceptance criteria, unit/functional/system/user tests, verification, and validation applicable and all other available information.
STEP 6 – DISCUSS SOW FOR THE USER STORY
A member of the team whom is most knowledgeable about the work to be accomplished briefly (~30 seconds) discusses the scope of work for the user story and any special circumstances.
STEP 7 – Q&A
After the user story is described, there is a short (~1 minute) period for team members to ask questions to clarify SoW, address risks, impediments, et cetera that are relevant to the estimation of effort of that particular user story. Other topics related to the user story should be avoided and discussed at another time.
Based on Q&A it could be determined during the estimation that the card is blocked or voted as infinite. Or perhaps someone votes for a coffee break. In any case, if a user story is determined to be blocked or not clear enough for estimation it should be tabled immediately and the team should move on to the next estimation.
Important team dynamics to consider:
- Scrum teams are self-organized
- During planning poker, all votes and view points are equal
- it is critical to keep time box discipline
- deliberate disruption is non-productive and should be addressed outside of the planning poker session
- remember that collaboration as a team will generate the greatest benefits and most accurate estimates
- the team determines the rules (no house rules)
STEP 8 – PLAY YOUR HAND – ESTIMATE
The team lead (engineering lead or scrum master) will then ask the team to prepare their estimate/vote. If the meeting is being held remotely via video conferencing software (e.g. – google+ hangouts) then the vote should be made simultaneously using the Chat feature (have found this works great). If in person, use physical planning poker cards. All team members should vote simultaneously.
IMPORTANT: It is critical that all team members vote simultaneously.
NOTE: for remote teams, the team lead should make a clear demarcation in the chat window between votes. There are tools specifically designed for planning poker on remote teams that I will discuss in another article.
STEP 9 – REVIEW VOTES
So, all the team members voted. Great. There is a good possibility that there will be a large range of estimates (for younger teams). The high and low estimates / votes will cause a short side bar (1m-2m max) where one each of the high and low estimates must be defended by a team member. The intent is to provoke thoughtful discussion, defense. and debate amongst experts. Once the high and low estimates are defended the user story is re-estimated (back to step 7).
Important team dynamics to consider:
- No team member should be attacked or otherwise negatively displayed; all votes are valid as part of the process
- Defense of an estimate by a team member is a critical aspect of generating value from the process
- Debate for an estimate by the team is a critical aspect of generating value from the process
Step 10 – RECORD ESTIMATE
If all of the played votes are the same (or with only 1 outlier) than consensus has been reached. Someone on the team should immediately record the user story story point value (paper, system of choice; e.g. Jira) determination. Then, move on to the next user story to estimate.
Next Steps
-
Research and learn more about Scrum (scrum.org, Why Scrum?)
-
Research and learn more about (Agile) Planning Poker
- Ask questions here on the Blogagility article and I will do my best to answer them.
Custom Planning Poker Deck License
This work is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License. You are free to download, print and use the poker deck as-is without modification.
blogagility.com 