Planning poker is an effective way for Agile teams to get to a shared understanding with Product Owners. (Unsplash)
Planning poker is an effective way for Agile teams to get to a shared understanding with Product Owners. (Unsplash)

Planning Poker is a technique Agile software development teams use to estimate the work presented to them by the Product Owner. It allows the software development team members to discuss features requested by users and provide feedback about the effort required to bring those features to production.

1 - “You shall bring no time estimates to Planning Poker.”

Substantial research has indicated that people are bad at estimating how long something will take. In my experience, software developers are overwhelmingly optimistic people. This usually results in estimates that are far too small when compared to actual results.

2 - “You shall not take for yourself a user story that does not match the likeness of the Definition of Ready. You shall not discuss or size such a story, for the software we build is jealous, visiting the iniquity of Un-Ready work on Developers, on the third and fourth sprints of those who size such work, but showing lovingkindness to thousands, to those who heed the Definition of Ready, to those who want to get work to Done within a Sprint.”

The Definition of Ready is a list of characteristics, agreed upon by the Scrum Development Team and the Product Owner, that must be met before a user story can be discussed and sized.

3 - “You shall not take the Definition of Done in vain, for the work will not leave Developers unpunished who size ignorant of the Definition of Done.”

The Definition of Done is a list of the characteristics a user story need to have in order to consider it done. When estimating, it’s vitally important to think it terms of the entire development process including designing, testing, and deployment in addition to writing code.

4 - “Remember completed stories, to keep them holy. You completed stories of various sizes in previous sprints, and you should use those as a relative guide for estimating. You shall not size without considering completed stories, you or your son or your daughter, your tester or your designer or your programmer or the manager who stays with you. For in previous stories the team made the heavens and the earth, the sea and all that is in them, and sized them all; therefore the work has been made shippable and made holy.”

Planning Poker is an exercise is relative sizing. It’s important that you look at completed stories for examples of various sizes. You can then compare these to the stories being sized and determine if they are larger or smaller.

5 - “Honor your fellow estimators, that your work may be Done in the upcoming sprint.”

Sizing stories can be contentious, and it’s important that participants treat each other with kindness and respect. The goal is not to “win” the sizing. The goal is to come to a better shared understanding of the work.

6 - “You shall not allow anyone to size stories who will not do work in the upcoming sprint.”

The only people who can size the work are the people who will do the work.

7 - “You shall consult with the Product Owner.”

Ideally, the Product Owner is present during the sizing exercise to answer any business or product questions about the work.

8 - “You shall not steal the estimate of another.”

It’s easy for junior members of the team to not be intimidated by senior members of the team. This is avoided by having all Planning Poker participants reveal their sizes at the same time. However, it’s important that everyone stick to the size they’ve chosen unless they find technical information they had not considered.

9 - “You shall not prematurely show your estimate. That is an abomination.”

When using physical cards when playing Planning Poker, it’s possible for a participant to surreptitiously show their card. It’s important to not do this and unduly bias the exercise.

10 - “You shall not base your estimate on how you think other estimators size cards. You shall not base your estimate on how little or how much work you think the team should do during the sprint. You shall only base your estimate on the merits of the story and on the merits alone.”

The size is based on the work item being discussed and only on the work item being discussed. All other considerations should be ignored.