Planning Poker for Improved Project Delivery

Abstract

A project is a temporary formation of people, typically formed in order to create value for a business in the form of a solution, a service, a product or similar. The ability to complete a project successfully relies on a team’s ability to meet the goals of the project, on time and on budget. A key element to delivering a successful project is the accurate estimation of how much work needs to be done to reach the goals of the project, how the work will be broken down so it can be achieved and when each task should be initiated. If teams do not plan accordingly, deadlines will not be met, risking delays and the success of the project.

This article will cover the aspect of effective planning for successful project delivery through the use of an estimation technique known as Planning Poker. Typically used in an Agile approach to project management, Planning Poker helps teams more effectively judge how long tasks will be take to complete, by including different expert opinions from the team when estimating. More accurate completion times for tasks allows for better project planning, better project execution and a more realistic deadline for the project, helping meet business objectives and stakeholder expectations on time and on budget.

The Big Idea

As listed by the PMBOK® Guide the completion of a project is reached when all objectives have been achieved, the solution has been created, resources have run out or if the project is discontinued due to new priorities. From the beginning of a project until its completion, a project goes through different phases, referred to as a project’s Life Cycle and typically include:

• “Starting the Project”
• “Organising and Preparing”
• “Carrying out the Work”
• “Ending the Project”

A successful and valuable project is one that delivers the right value at the right time. It clearly defines what work needs to be done, how that work will be done, and when it will be done. Given the temporary nature of a project the success of a project ultimately comes from completing all four steps in a project’s Life Cycle in a timely matter, ensuring that the right work is delivered at the right time. The importance of successful project management allows stakeholder expectations to be met, by delivering on business objectives by solving the right problems at the right time. A project backlog, or activity list as it is also referred to in the PMBOK® Guide refers to the list of tasks that need to be developed, tested and put into production to complete a project. The length of time needed to complete these tasks is the length of time a project will take to deliver. Estimating the time needed to complete all tasks is of vital importance to the development of an accurate timeline. It is also vital that all tasks listed in the activity list are described 'in sufficient detail to ensure that project team members understand what work is required to be completed' to improve estimates. The PMBOK Guide<red name=PMI/> lists several different estimation methods typically used by teams and include:

• Expert Judgement
• Analogous Estimating
• Parametric Estimating
• Three-Point Estimating

In all of the estimating methods listed above, the focus for estimating work for the upcoming project comes from either an expert with relevant knowledge about the tasks at hand, or based on completion times of historic projects. None of these estimation methods consider both an iterative based estimation process and the ability to draw from present day knowledge regarding tasks. These estimation techniques either fully reply on a single individual (Expert Judgement), historical methodologies to problem solving (Analoguos Estimating), lengthy algorithm creating tasks (Parametric Estimating), or taking averages of best, average and worst case scenarios (Three-Point Estimating). For improved project delivery in the future, a quicker, more encompassing and less error prone tool needs to be used, and some of these elements can be solved by using Planning Poker.

Planning Poker

Planning Poker is a tool used to more accurately measure the sizes of work tasks that need to be completed within a project. It does so through effectively drawing knowledge from all individuals in a team, with varying competencies, in an iterative process. In combines expectations of workload for a task, and allows the team to reflect and ask more questions regarding the tasks, and doing this without introducing cognitive biases.

To begin the process, the total activity list is evaluated to find a simple task, one that can be created and tested within a day. This tasks that i can be completed within a day is designated a story point of 1. This becomes the task benchmark for all other tasks, and will be the reference point for which all other tasks will be measured against. In Planning Poker, all tasks are compared relatively to each other and not specifically with regards to the number of hours a task is expected to take to complete. The estimating process is therefore done by estimating how much longer a task will take in relation to the benchmark task of 1 story point.

Figure 1: The cards found in a typical Planning Poker deck

The estimation process is guided using 13 Planning Poker cards, which include 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? (unsure) and ∞ (this task cannot be completed), and is based off the Fibonacci sequence.

The cards, and therefore the estimating intervals are an adapted version of the Fibonacci sequence, a pattern of numbers often encountered in mathematics and the natural world.

The cards are guided by the Fibonacci sequence due to the large uncertainty that comes with estimating larger numbers. The accuracy in deciding whether a task is 40 or 41 story points larger than the benchmark is negligible in such large numbers. For Planning Poker estimates, the card 0 indicates that the task is already done and no more work is required to deliver on it. A ½ means that the specific tasks is almost done and can be completed in half the time of the benchmark tasks. Playing the card with a 1 represents that the task requires approximately the same amount of work as the benchmark tasks. A 2 signifies that the tasks is estimated to take double the time as the benchmark task as so it continues for all the cards. The ? can be played if a member does not feel they have adequate information regarding the size of the task. This could be due to several significant uncertainties, or that the scope is not defined enough and that it is unknown at which point in time the task can be considered completed. The ∞ signifies that this task cannot be completed. Some Planning Poker decks also include a coffee card, which signifies the need for a break.

When done correctly, Planning Poker should provide better estimates than those reached by individual experts , and especially better than estimates provided by inexperienced individuals, by allowing all developers within the team regardless of their experience, to be a part of the estimation process. It removes cognitive biases and can help catch unconsidered scenarios and challenges that otherwise could be missed when expert judgement is solely used. The estimation process involves all members of the development team, namely the team who will be delivering work for the project, and in this way all taks are agreed upon by the team, hereby increasing a teams commitment to meeting the deadline for a task.

Application of Planning Poker

Once the entire development team has been gathered, Planning Poker can begin. Below describes the seven steps involved with carrying out Planning Poker.

1. A mediator who is not included in the game, and therefore not handed any cards, is in charge of facilitating the meeting. This involves keeping track of time, speeding up meaningful team discussions, and deciding when the team needs to move on to the next step. He is ultimately in charge of ensuring that the team go through all the tasks in the backlog within the allotted time.
2. The Product Owner (known as the person who is in charge of deciding what increments of value need to be delivered in the project), presents the a task to the team. The product owner participates in the event through asking and answering questions but does not vote, as she is not involved with delivering any of the tasks. The team is then allowed to discuss amongst themselves, and ask questions to the Product Owner, to clarify assumptions, risks and ensure an understanding of the scope of the task. Members are not allowed to discuss numbered estimates during this time. Discussions are time-boxed to a few minutes by the mediator with help from the Product Owner, and once this time is up, all discussion stops and the team moves onto the next step. The Product Owner introduces all tasks, one at a time.
3. After all the discussions from the step before, all team members participating in Planning Poker now secretly select one of the 13 playing cards, representing their idea of how much work is needed to complete a task, relative to the benchmark task (the task that was estimated to be developed and tested successfully within a day). All cards are laid face down on the table by all members.
4. All at once, all participants turn over their cards, revealing their estimates.
5. The participants that selected the highest estimates and the lowest estimates are given the chance to talk, and justify why they, in their opinion, believe their estimate reflects the task. They bring up points potential issues, or previously established methodologies that they believe will speed up or slow the completion of the task. After these outliers have been explained, another round of discussions by all participants is allowed, also timeboxed by the mediator/Product Owner.
6. Another round of estimates begins, and players again secretly select the number they believe best reflects the amount of work for the task, taking the most recent discussion and points of view into account. Cards are laid face down on the table once more.
7. On the mediators command, all players simultaneously show their cards, and the outliers (highest and lowest score) are explained again. If consensus has been reached, the task is given the agreed upon size, and the team moves onto the next task.

The estimation rounds maybe continue past two rounds, but the moderator should be ready to bring discussions to a close due to the diminishing accuracy increases that each round brings. Teams should not continue discussions endless, and should rather agree on an estimated size for the task, so as to ensure that all remaining tasks are also estimated within the time available. An estimation round can also be concluded after one round, if consensus is reached, and if everybody is in agreement. When Planning Poker is conducted in this structured way, all members of the development team participate in estimating the task, and all voices are heard. In this way, influential individuals or those that are the loudest or most opinionated do not dominate the estimates. All members of the development team who will work on delivering the tasks must participate, even if they are not the most knowledgeable in the specific area of the task so that all perspectives, ideas and opinions can be considered by the team. A study by Moløkken-Østvold and Jørgensen (2003) showed “that people with less knowledge in the area employed different estimation strategies that provided different perspectives on the required effort, improving the group estimate”,, and varying views are therefore vital for the accurate estimation of tasks from the team. The technique of playing Planning Poker in itself is not what creates the most value, but rather, the discussions that stem from varying viewpoints, reflected in the different scores given by each team member, is how the tool creates value. Facilitating discussion and contrasting viewpoints so that the experts within the team also have a chance to considering possible influences not otherwise included in their estimates. According to study published by Haugen (2006) , Planning Poker can be used to reduce the bias of anchoring, in which a team member expresses his opinion of the problem to the rest of the group leading to other group members knowingly or unknowingly changing their estimates to reflect that benchmark. It also states that Planning Poker increases in accuracy the more experience and familiar a team gets in estimating similar tasks.

Limitations of Planning Poker

Although a tool with many benefits, Planning Poker does have some shortcomings, and these will be described in the sections below.

Like any tool, Planning Poker requires a Planning Poker card set for each member participating in estimations. This tool also comes with a set of rules that need to be understood and follow for it to be effective. A misunderstanding that can arise is the notion of estimating tasks in story points. These story points should not strictly be considered as number of hours taken to complete the tasks, as this is far to specific. Story points should however reflect the following four aspects

1. Volume: How much work is there
2. Complexity: How hard is the task
3. Knowledge: What is known about the task
4. Uncertainty: What is unknown about the task

Story points therefore focus on a relative comparison rather than a strict time comparison. They do include a sense of time taken to complete, but by making the comparison relative, Story Points also include other factors that can be harder to estimate in strictly time units.

Experience

The better the team know the tool, and the more experience they have with the tool, the better they utilise the tool, and stated earlier in. The study by Haugen (2006) also suggests that Planning Poker can be less accurate when a team has no experience in estimating tasks, or no experience from similar tasks to draw from, which can prove a liability for some teams. Planning Poker can also lead to increases in the extreme estimates of a group, as group members can become blind to the problem and suffer from the cognitive bias of group think, where team members begin agreeing with each other, believing that group opinion must be correct.

Many negative aspects can be removed from Planning Poker when it is conducted with experienced and knowledge moderator and product owner, and if the rules are followed. If Planning Poker is not held in a structured way, you risk that some members of the team keep their estimates and opinions to themselves, allowing louder members to dominate the discussion. These dominating perspectives can lead to anchoring, group pressure, members to feel company politics, group think, and other cognitive biases. These cognitive anchors and external influences can lead to more inaccurate estimates if care is not taken.

Although seen as a time efficient estimation tool, if not time boxed well by the moderator teams can continue estimating a task, discussing their points of view, then re-estimating in their pursuit of a unanimous decision. The accuracy of Planning Poker suffers from a diminishing rate of return, and therefore the continuing past two estimation rounds typically reveals little extra value, for the extra time spent, and such behaviour should be avoided.

Diminishing rate of returns

Explain why

Conclusion

Although suffering from certain risks, when Planning Poker is structured, used correctly and when a team have knowledge on a subject, can result in more accurate estimations, sometimes better than those estimations coming from experts estimating in isolation. The advantages from using this tool to estimate tasks in a project include removing cognitive biases, complete team participation, drawing from knowledge throughout the team, and an iterative approach to refining estimates.

Annotated Bibliography

[2] Cohn, M., "Agile Estimating and Planning", Prentice Hall, November 2005. Retrieved on 18 February 2019: This book lays the foundation for estimating and planning in an Agile mindset. Written by Mike Cohn, who popularised the methodology for estimating tasks, it lays out everything needed for understanding and applying the Planning Poker tool in a team setting. Great resource for learning about the need for Planning Poker in teams.

[4] SAFe, "Story", October 2018. Retrieved 21 February 2019 A link to the scaled agile framework (SAFe) website, this resource is the official homepage for all this SAFe related.