What is a planning poker (& Facts)
- Planning poker is a consensus-based technique to estimate the effort in an Agile project. It is sometimes referred as scrum poker as well.
- Performed using a deck of cards (referred as planning poker cards). The Fibonacci sequence (i.e. 1, 2, 3, 5, 8, 13, 21, 34…) are printed on cards (most popular and widely used). One can use any other sequence which suits your need. For instance, doubling card numbers (1/2, 1, 2, 4, 8, 16, 32…) is quite popular as well. These numbers represent story points.
- You can leverage software tools(tons of tools available online) over cards to make the process easy and compiling estimation for each story.
- The teams come to approx estimate and keep getting better with time.
- It’s a collaborative effort and team activity. The entire team is expected to participate in this activity. If your scrum master is going contribute technically then he/she should participate along with programmer, testers, DBA etc. If the scrum master is not going to contribute technically while he/she has a solid technical background then it is advisable to include him.
- The PO may be included too if he/she has strong technical background.
- It is derived from WBD (Wide Band Delphi), Analogous and WBS (Work Breakdown Structure) estimation methodologies.
- The stories should be broken down enough so that estimation will not go beyond. One general rule is to break down the tasks further if it is scored 13 or above. There are instances where you cannot really do that while in most cases it’s not very tough to do so.
- The voting option can always be used when there is a conflict in estimate post discussion.
- If the estimation is done using story points then its easy to sum them up to match velocity so that sprint commitment can be made. The hours is not advisable as by definition user stories are a high-level description of functionalities hence chances are slim to get close to accurate hours when estimating.
- One of the team members is selected as moderator (Typically product owner or scrum master)
- Every individual is given deck of cards with numbers printed on it. If the software product is used over cards, a session is created and everyone logs into that to select their number for every story.
- The moderator reads out the story loud with all the details. The whole team discusses to ensure everyone has a fair understanding and missing items are covered.
- During this discussions, any question which comes with respect to functional details, PO answers that. Remember, it’s a collective effort hence anybody who has more context can clarify the doubt though a final decision is taken by PO when it comes to functionality.
- Every individual secretly selects his/her card representing their estimate which is later shown to the rest of the team once everyone is done with their estimate for a given story.
- If the entire team come to the same estimate, it becomes an estimate for a given story.
- Team members which have higher or lower estimate compare to rest of the team would explain their viewpoints. The team can take some time to discuss that further. If needed, this process is repeated for the same story or the whole team agrees on one final number.
- This estimation process is repeated for every story.
- It is perfectly alright to have a varying estimation as the team gets mature over a time and moreover, understanding of business and technology will keep getting it better.
- Better understanding of requirements because
- The entire team is involved in estimation and
- Discussions around each story specifically unknown areas.
- It’s easy and a fun way to estimate.
- The estimates are not dumped instead its collective team estimate. This leads to high morale, a greater sense of ownership, team responsibility and commitment.
- Everyone has a say on the estimation. The equal voice whether an individual with zero or 10+ years of experience creates trust and positive environment.