Revision as of 21:26, 27 February 2019

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.^[1] 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.^[2] 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.^[1]

The Big Idea

As listed by PMBOK® Guide^[1] the completion of a project is reached when all objectives have been achieved, the solution has been created (or cannot be 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 clearly defines what needs to be done, how that work will be done, and when it will be done, and going through a project’s Life Cycle in a timely matter ensures that the right work is delivered at the right time. The importance of successful project management allows stakeholder expectations to be met, business objectives to be delivered by solving the right problems at the right time. To ensure that a plan is effective, it has to be realistic in terms of timeline. A realistic timeline includes an evaluation of all the tasks that need to be completed, and it is therefore critically important for a project to be able to estimate its work effectively, so as to create an accurate timeline.

For a project to be successfully achieved, all tasks within a project backlog need to be completed. A project backlog, or activity list as it is also referred to in PMI^[1] 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. Therefore estimating the time it will take to complete these 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'^[1] to improve estimates. The PMBOK Guide<red name=PMI/> lists several different estimation methods, including:

• 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 process where different members of a group can voice their estimations and refine their estimates thereafter as well as drawing from present day knowledge regarding tasks.

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 from knowledge throughout the team on how long a task should take, and comparing the teams deviating expectations of the workload within a task, without introducing cognitive biases.^[2]

Within a total list of tasks that need to be delivered, a simple task, one that can be created and tested within a day, is selected and 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. This is done by estimating how much longer a task will take in relation to the benchmark task with 1 story point. 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. ^[3] 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. [Scrum institute.org] 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 ^[4] For Planning Poker estimates, the card 0 indicates that the task is already done, a ½ that it is almost done, a 1 that it is the same amount of work as the benchmark, 2 that it will take double as the benchmark task as so on. The ? is if you do not feel you have any adequate information regarding the task, and the ∞ signifies that this task cannot be completed. When done correctly, Planning Poker should provide better estimates than those reached by individual experts ^[5] , 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. The estimation process involves all members of the development team, namely the team who will be delivering work for the project, to estimate all tasks, for the team to establish an estimate of how much time the tasks will take relative to each other.

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. ^[6]

1. A mediator who is not included in the game, is in charge of facilitating the meeting.
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 tasks 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 timeboxed to a few minutes by the mediator or Product Owner, and once this time is up, all discussion stops and the team moves onto the next step.
3. In this step, all members of the team playing Planning Poker secretly select one of the 13 playing cards, representing their idea of how much work is needed to complete a task. 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. People 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. After these outliers have been explained, another round of discussions 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. Card are laid face down on the table again.
7. On the mediators command, all players simultaneously show their cards, and the outliers (highest and lowest score) are explained again. Once 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, and get the team to agree on an estimated size so as to estimate the remaining tasks 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. ^[7] 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 views and ideas 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”^[7], and 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) ^[6], 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, and the other group members knowingly or unknowingly change their estimates to reflect that benchmark. It also states mentions 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^[8]

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.

The next aspect influencing effectiveness of Planning Poker is that of 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) ^[6] 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.^[6][9] 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. Such behaviour should also be avoided

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.^[7] 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. ^[7]

References

1. ↑ ^{1.0 1.1 1.2 1.3 1.4} Project Management Institute Inc. (PMI), 2017, "Guide to the Project Management Body of Knowledge", 6th Edition.
2. ↑ ^{2.0 2.1} Cohn, M., "Agile Estimating and Planning", Prentice Hall, November 2005. Retrieved on 18 February 2019.
3. ↑ SAFe, “Story”, October 2018. Retrieved 21 February 2019.
4. ↑ Scrum Institute, “Scrum Effort Estimations – Planning Poker®”, 2018. Retrieved 21 February 2019.
5. ↑ Mahni, V., Hovelja, T., 2012, "On using planning poker for estimating user stories".
6. ↑ ^{6.0 6.1 6.2 6.3} Haugen, N., 2006, "An Empirical Study of Using Planning Poker for User Story Estimation", IEEE Computer Society.
7. ↑ ^{7.0 7.1 7.2 7.3} Moløkken-Østvold, K., Haugen, N., Benestad, H., 2008, "Using planning poker for combining expert estimates in software projects".
8. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named SAFE
9. ↑ Børte, K., Ludvigsen, Mørch, A., 2012, "The role of social interaction in software effort estimation: Unpacking the ‘magic step’ between reasoning and decision-making".