Latest revision as of 17:12, 4 March 2019

Developed by Keegan van Kooten

[edit] Abstract

A project is a temporary formation of people, gathered 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 and deliver it 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 long the work needed to reach the goals of the project will take to complete, 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 accurate estimations of work needed to successfully deliver a project, 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]

[edit] The Big Idea

As listed by the PMBOK® Guide^[1] (Project Management Body of Knowledge) 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. 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.^[1]

A project backlog, or activity list as it is also referred to in the PMBOK® Guide^[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. 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'^[1] to improve estimates. The PMBOK Guide lists several different estimation methods typically used by teams and include:^[1]

• 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 in a team. These estimation techniques either fully reply on a single individual (Expert Judgement), historical methodologies to problem solving (Analoguos Estimating), creating lengthy algorithms(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.^[3][4]

[edit] Planning Poker

Planning Poker is a tool used to more accurately measure the sizes (and therefore the time need) of work tasks that need to be completed within a project. It does so through effectively drawing knowledge from all individuals in a team, who vary in competencies, in an iterative approach. It combines expectations of workload expected for a task, and allows the team to reflect and ask more critical questions regarding the intention and scope of a task, all without introducing cognitive biases or other possible influences.^[2] A cognitive bias is when judgement is unknowingly no longer rational and leads to ineffective and faulty decision making.

[edit] Cognitive Biases

A cognitive bias occurs when a person's perception is influence or pressured by external factors. These factors can stem from environments of group pressure, company politics, group think or less obvious factors such as:^[3][5]

• Group Think: Also known as Bandwagon Effect, is when members of a team believe what the rest of the team believes
• Priming Error: When a person is influenced by a previously stated opinion from another person
• Affinity Bias: When a person tends to be biased towards others whom are similar to themselves
• Self-serving Bias: When a decision is made on vague or missing information whereby a person is biased towards what would best benefits their personal interests
• Attentional Bias: When a person's perception and opinion is influenced by recurring thoughts
• Belief Bias: When the logical strength of a person's argument is based strongly on the strength of the argument's conclusion
• Confirmation Bias: Looking for and noticing information that reinforces your own perspective

These cognitive biases and external pressures can influence team members and there honest opinions, unique perspectives to be lost, and can lead to more inaccurate estimates if care is not taken.

[edit] Setting up Planning Poker

To begin the process of Planning Poker, the total activity list is evaluated to find a simple task, one that can be created and tested within a day. This tasks that 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 larger a task is in relation to the benchmark task of 1 story point.

Figure 1: The cards found in a typical Planning Poker deck^[6]

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

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.^[8] 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.^[8] 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 the point at which the task can be considered successfully delivered is unknown. 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 can provide better estimates than those reached by individual experts^[3], 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. When structured well, Planning Poker is also a time efficient means for estimating tasks, and teams get quicker with experience^[9]. 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 tasks are agreed upon by the team, hereby increasing a teams commitment to meeting the deadline for a task.^[7]

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

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, and according to the rules.
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 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. After the task has been read out, 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.
3. Considering 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 the task, relative to the benchmark task (the task that was initially selected to be successfully developed and tested within a day). All cards are laid face down on the table by all members.
4. All participants turn over their cards simultaneously, revealing their estimates.
5. The participants that selected the highest estimates and the lowest estimates are given the chance to talk, and justify why in their opinion, their estimate reflects the task. They bring up potential issues, or previously established methodologies that they believe will speed up or slow down the completion of the task. After these outliers have been explained, another round of discussions by all participants is allowed, also time-boxed by the mediator/Product Owner.
6. After these new discussions have finished, 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 may continue past two rounds, but the moderator should be ready to bring discussions to a close due to the diminishing benefits to estimation accuracy that each round brings. Teams should therefore not continue discussions endlessly, 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. According to Haugen (2006), 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. The opinions of influential individuals or those that are the loudest or most opinionated do therefore, not dominate the estimates.^[9][10] 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”^[10], 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 inherently where the value is derived but rather, the effectiveness of this tool stems from the discussions that it facilitates through exposing varying viewpoints, reflected in the different scores given by each team member. Facilitating discussion and contrasting viewpoints so that the experts within the team also have a chance to considering possible influences possibly not otherwise included in their estimates. Assumptions are namely checked, opinions are aired, allowing the whole team to consider all known information to more accurately estimate a task. It also states that Planning Poker increases in accuracy the more experience and familiar a team gets in estimating similar tasks.

[edit] 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 some equipment is needed to facilitate the process, and 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 followed 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 tasks, as this is far to specific. Story points should however reflect the following four aspects:^[7]

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 in time needed to deliver a task, rather than a specific 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. This provides more flexibility when estimating larger tasks, and does not hold a team to a specific time for when a task will be complete, but rather which half day a task should be ready^[7]. Below, the possible limitations of Planning Poker are described in sections.

[edit] Experience

The better the team know the tool, and the more experience they have with the tool, the better they can utilise the tool. Although Planning Poker typically facilitates better estimates, the study by Haugen (2006) ^[9] 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 through group think, and although Planning Poker helps remove this risk, teams suffering from group or organisation pressure can become blind to the problem at hand, and begin agreeing with each other, believing that group opinion must be correct, an exeagerating extreme estimates both small and large.

Many negative aspects can be removed from Planning Poker when it is conducted with an experienced and knowledgeable 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, group think, and other cognitive biases.^[9][11] These cognitive anchors and external influences can lead to more inaccurate estimates if care is not taken.

[edit] Duration

Although seen as a time efficient estimation tool, if not time boxed well by the moderator teams, the team can use many hours during estimating exercises. This can happen through Planning Pokers iterative process by which teams can continue estimating a task, discussing their points of view, then re-estimating in their pursuit of a unanimous decision. Other techniques such as White Elephant Sizing solve this issue by setting all estimating cards on a table, and a team one by one places a task at the estimate they believe best reflects the size of the task. The next member may then move this original task to another estimate, or take a new task and estimate that one. In this way, a team can process many more tasks in a given time span, but can suffer from the cognitive biases as described under the section of Planning Poker above.

[edit] Diminishing rate of returns

The accuracy of Planning Poker comes from its ability to highlight large discrepancies within a team. Once a discrepancy has been found, the tool then allows the team to discuss and re-evaluate their own opinions with new information given by the other members in the team, members who possibly have varying fields of expert knowledge. Incorporating a variety of information is key to an estimation process, but over time, Planning Poker suffers from a diminishing rate of return. As estimates are revealed, the gap between largest and smallest estimates tend to converge, and the value of Planning Poker, which was to highlight large discrepancies becomes less and less apparent. Therefore continuing past two estimation rounds typically reveals little extra value for the extra time spent, and should generally be avoided.^[7]

[edit] Conclusion

Planning Poker can prove very helpful for a team's estimates of varying tasks, through its ability to highlight estimation discrepancies within a team in a reasonably short amount of time. Although suffering from certain risks including its reliance on prior experience with the tool, a diminishing rate of return and possible excessive time spent estimating, these risks are mitigated when Planning Poker is structured, used correctly, and when a team have knowledge on a subject. In this environment, Planning Poker 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 during the estimation process, ensuring entire team participation, drawing from knowledge throughout the team, and an iterative approach to refining estimates by incorporating new knowledge. When executed in this way, Planning Poker ensures more accurate estimation of a projects activity list, hereby providing the foundation for more reliable and reasonable project estimates, satisfying stakeholders expectations, increasing team member's commitment to the work, leading to improved project delivery.

[edit] 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, and the specifics about, 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 material. An expansive library of information, this site provides clear, open and an extensive body of knowledge and descriptions into the working of the SAFe protocol, from which Planning Poker is an essential tool.

[8] Haugen, N., 2006, "An Empirical Study of Using Planning Poker for User Story Estimation", IEEE Computer Society. This paper is a study conducted by Nils C. Haugen to aid in the literature regarding estimation processes, as he notes that little progress has been made in this field in the last decades. This study looks at the effectiveness of a team who applied a Planning Poker estimation process versus when that same team applied a none structured approach to estimation of tasks, and detailing all of the findings from the study, discussing the possible threats to the results as well as the major findings.

[edit] References

1. ↑ ^{1.0 1.1 1.2 1.3 1.4 1.5 1.6} 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.
3. ↑ ^{3.0 3.1 3.2} Mahni, V., Hovelja, T., 2012, "On using planning poker for estimating user stories".
4. ↑ Miranda, E., Bourque, P., Abran, A.,"Sizing user stories using paired comparisons", ELSEVIER: Information and Software Technology, Published: April 2009.
5. ↑ Oswald, M., S., Grosjean, 2004, "Confirmation Bias". A Handbook on Fallacies and Biases in Thinking, Judgement and Memory. Hove, UK: Psychology Press.
6. ↑ WikiMedia, "CrispPlanningPokerDeck - Creative Commons" [1],
7. ↑ ^{7.0 7.1 7.2 7.3 7.4} SAFe, "Story" [2], October 2018. Retrieved 21 February 2019.
8. ↑ ^{8.0 8.1} Scrum Institute, "Scrum Effort Estimations – Planning Poker", 2018, Retrieved 21 February 2019.
9. ↑ ^{9.0 9.1 9.2 9.3 9.4} Haugen, N., 2006, "An Empirical Study of Using Planning Poker for User Story Estimation", IEEE Computer Society.
10. ↑ ^{10.0 10.1} Moløkken-Østvold, K., Haugen, N., Benestad, H., 2008, "Using planning poker for combining expert estimates in software projects", ELSEVIER: The Journal of Systems and Software, Published: March 2008.
11. ↑ 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".