Task Estimation with Planning Poker
If you dislike estimating tasks “by eye” and desire precise results, try playing Planning Poker.
Planning Poker is a task estimation technique for Agile teams. It is conducted using cards and resembles a poker game. The method was first described in an article by one of the authors of the Agile Manifesto, James Grenning.
In the Planning Poker estimation method, the entire team, led by the Scrum Master, participates—it’s a crucial condition. The Scrum Master distributes a deck of special cards to all participants. For remote teams, various online services can be suitable, while the estimation rules remain unchanged.
The Fibonacci Numbers are often used, which is a sequence of numbers starting with two ones, and each subsequent number is the sum of the two preceding ones: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89.
The deck may include cards with the following values:
- ? — uncertain answer;
- ½ — simple task;
- ∞ — infinitely long task;
- coffee break or an image of a coffee cup — a break is needed;
- cards with sizes S, M, L, or any others as needed.
Team estimation helps achieve an objective result. For example, a developer might know better how much time their work actually takes but may exaggerate its complexity to hedge and get more time. Therefore, the estimation process is always monitored by the facilitator. The idea is to consider the opinions of all team members and make the most accurate predictions.
If, after the voting, all cards are close in values, the team has estimated the task approximately the same, and it can be concluded there.
But what to do when there are contrasting differences? For example, two developers assessed the task differently: the Junior chose a card with a nominal value of 4, while the Senior chose 10. Ask each to express their opinion and listen to their arguments. You and the rest of the team will understand why they think so. For instance, the Senior may have inflated the number to get more time, although they can work faster. The Junior may have underestimated the task’s complexity due to inexperience. Usually, reality lies somewhere in between. After discussion, repeat the vote, now based on the new information.
If everyone quickly agrees, and you get the desired result, move on to the next task. If not, continue voting until the result becomes unequivocal. Your goal is the arithmetic mean of all estimates proposed by the team.
Tag:Agile, Project, Terminology