Planning Poker: Master Agile Estimation

Team collaboration and an innovative mindset are crucial characteristics of a well-rounded Agile team. These features can be better fostered through Planning Poker sessions, which are designed to eliminate the issue of calculating a project’s exact estimation.  

Deemed as a popular Agile technique, Planning Poker makes the estimation process very straightforward, helping teams streamline their project estimation. Discover the Agile estimation technique known as Planning Poker and how it enhances the accuracy of project planning. 

Table of Contents 

1) Understanding What is Planning Poker 

2) Mechanism of Planning Poker 

3) What is the Estimation technique in Planning Poker? 

4) Benefits of Planning Poker 

5) Drawbacks of Planning Poker 

6) Conclusion 

Understanding What is Planning Poker 

Planning Poker is the term used for the planning and estimation technique implemented by Agile teams after the creation of a product backlog. This technique can help software teams to estimate the time frames of their product’s development in an accurate manner. It also helps them improve collaboration within the team and better strategise the project work. 

Additionally, the Planning Poker technique is typically played by many estimators from all the departments. These estimators include the Scrum Master, Software Developers, Quality Assurance or QA Testers, Product Managers and User Experience or UX Designers. 

The technique is basically a consensus-based method for teams to apply relative estimates to planned project work. Now, the process of Estimation in Planning Poker can be very beneficial if done appropriately, helping the team handle large-scale and sophisticated projects by segregating them into smaller, more manageable parts.  

Moreover, the Planning Poker technique was introduced to tackle the challenge of extra efforts by a team to achieve the correct estimation for the project. The technique significantly helped in streamlining the process of estimation. It basically helped an Agile team to come up with an estimation of the time and effort necessary for the completion of a project. 

Furthermore, the technique was designed with the intention of helping companies estimate their timelines with more accuracy and improve their teamwork abilities. It is a fun session that boosts the team's overall morale, ensuring that all members are better aligned with the idea of collaboration and interaction. These practices help them deliver the product quickly and with high quality.
 

A brief history of Planning Poker 

Also called ‘Scrum Poker’, Planning Poker is a gamified method for the process of estimation. It is typically utilised for timeboxing in Agile principles, which are based on Agile practices that facilitate the improvement of teams as self-organising and cross-functional entities. 

Now, the technique was first defined and coined by Agile Coach and Consultant James Grenning in 2002 and popularised internationally by Mike Cohn, a founder of the Scrum Alliance. 

Mechanism of Planning Poker 

Here is the process of Planning Poker, described in detail as follows: 

a) Induction of new joiners: The estimators must help the new joiners get aligned with the process of Planning Poker. The new joiners can be allowed to observe the game session so they can participate in the next game. The Scrum Master or the Project Owner can participate as the moderator and choose to exit the game room for discussion when necessary. 

b) Poker card distribution: The next step would be to distribute the poker cards among all the participants and to ensure that each of them receives an equal set of numbered cards. It is also important that the card sets in Planning Poker display the numbers following the Fibonacci sequence. The Planning Poker Fibonacci sequence has been suggested by Mike Cohn to follow the series of 0, 1, 2, 3, 5, 6, 13, 20, 40 and 100.  

c) User story reading: The Scrum Master then reads a user’s story from the sprint out aloud. The story comprises all the context and minute details of their business requirement. The story read mainly helps the team pay attention to the fine details.  

d) Group discussion:  After the user story reading session commences, the participants get involved in a group discussion. At this point of the Planning Poker session, the Scrum Master encourages the participants to put forward their questions pertaining to the user story. Each team member is then allowed to devise a solution to solve the questions. These solutions cover human and technical resources, tools, and so on.  

Master Agile interview questions and impress recruiters. Access our expertly crafted guide today!

What is the estimation technique in Planning Poker? 

Many estimation techniques for implementation in your Agile project exist based on the business requirement. Here is a list of the key Estimation techniques in Planning Poker, described as follows: 

Work Breakdown Structure or WBS 

A common technique to improve productivity during a project is to break down the work into smaller, more manageable tasks. The Work Breakdown Structure or WBS is a tool designed by the Program Evaluation and Review Technique (PERT) under the United States Department of Defence (DoD) in 1957. In 1962, DoD, NASA and the Aerospace markets published documentation pertaining to the PERT system, which described the WBS approach. 

Here is a list of the key steps to follow for calculating the estimate: 

a) Step 1: Create the Work Breakdown Structure by partitioning the project into smaller and more manageable portions. 

b) Step 2: Further break down the portions into accessible modules. 

c) Step 3: Break down the smaller sub-modules into functionalities. 

d) Step 4: Now partition these functionalities into smaller sub-functionalities. 

e) Step 5: Do a review of the project requirements and make sure that all details are included in the WBS. 

f) Step 6: Now estimate the effort and total time consumed to finish each task. 

Wideband Delphi technique 

The Wideband Delphi is a method utilised for estimating effort and is typically applied to estimate a variety of tasks, ranging from statistical data collection to sales forecasts. Introduced by Barry Boehm and John A. Farquhar in 1970, the Wideband variant fostered better interaction and improved communication among participants.  

Now this variant was of the Delphi method, which is a structured form of communication designed as a systematic method for forecasting, reliant on a panel of experts. It is widely utilised for business forecasting and has an edge over conventional structured forecasting methods like prediction markets. 

More importantly, the Delphi method is founded on the principle that the decisions made by a structured group of participants hold more accuracy than those from unstructured groups. With regard to a Planning Poker session, the technique forms a team of three to six participants, and the Work Breakdown Structure is then distributed among them. Their task involves the re-estimation of tasks, followed by their preparation of the final estimate, including the summarisation.  

It is important that the participants are experienced professionals, as their individual estimates would translate to more reliability in the results. Participants also need to remain anonymous throughout the estimation process, which also helps them convey their results with more confidence. Moreover, any assumptions made are carefully documented and discussed among all. 

Work competently with an Agile team by signing up for Agile Project Management Foundation & Practitioner (AgilePM®) now! 

Testing/Function Point Analysis 

A function point describes the application’s functionality from the perspective of the end user. The technique is designed for calculating the estimated efforts to complete a project. In the case of testing, the project’s estimate is fixed depending on the user’s requirement. The previous prototype of the project could also be utilised to help calculate the new estimate.  

There are cases where some components may need to be calculated, such as: 

a) Capers Jones basic formula: American software specialist Capers Jones published a collection of empirical rules based on his experience with estimating the various parameters of many software projects. He devised a formula which computes the function points to calculate the number of test cases, which is: [Number of test cases = (Number of function points) * 1.2. Once the test cases are calculated, the project team can extract productivity data from an organisational database and find out their estimate for testing. 

b) Total Actual Effort or TAE: A project’s Total Actual Effort is the efforts used to implement the project. It is the actual scope of resources that are applied to perform the software development cycle successfully. The TAE of a project can be calculated by using the formula: [(Number of test cases) * (Percentage of effort in development / 100). 

c) Non-adjusted Transaction function points: This is the main component of the estimation process where all function points generated from the Function Point Analysis or FPA are added and then labelled as Unadjusted Transaction function points. These FPA components comprise the External inputs, External output, Internal and External logic files and Inquiries. 
The formula for calculating the non-adjusted FPC is as follows: Non-adjusted FPC = ILFs + EIFs + EIs = EOs + EQs 

Experience-based testing Estimation technique
 

The technique of testing estimation based on experience relies on the skill and experience of the Software Testers, users and experts. The technique is done in an ad-hoc fashion because of the unavailability of proper specifications for testing the software applications. In such scenarios, the software testers rely on their previous experiences with the same software technologies.  

As per their experience, the testers pay attention to the important portions of the software, such as the parts that are most utilised by the customers or those that are highly likely to fail. Experience-based testing estimation methods are typically utilised for low-risk systems. Such testing is also conducted in the case when there are no specifications or an incomplete specification list. 

Here are the different types of experienced-based testing methods: 

a) Exploratory technique: This technique is an approach designed to foster simultaneous learning, test design and execution. The approach is pivotal in discovery and depends on the guidance of the tester to reveal the defects in the software which are not easily discovered while running other tests. 

b) Error guessing technique: This technique is designed to utilise prior experience in software testing to reveal software defects. The tester basically utilises their experiences from previous test cases to assess the problematic sections of a software application. 

c) Checklist-based testing:  This is a technique in software testing where a list of specific steps is created so they are conducted while testing a software application. Testers utilise the checklist as a guide as they perform their tests and abide by each step in a systematic manner. The results of the tests are also comprehensively documented. 

d) Fault attack testing:  This is a technique devised for enhancing the total area of the whole test. The enhancement is done by introducing faults in the software application to test its decision-making abilities. An error may be caused by the fault when the code is executed, which is referred to as an invalid state in systems. 

Percentage distribution 

Percentage distribution is a technique devised where every stage of the Software Development Life Cycle or SDLC is assigned some percentage. This percentage is allocated based on the previous data from similar projects. Here is a table highlighting some example percentage distributions in a project: 

Enhance customer satisfaction with Agile methodologies by signing up for Agile For Teams now! 

PERT Software Testing Estimation technique 

The PERT Software estimation technique is a method reliant on statistical methods where every testing activity is broken down into smaller sub-tasks, followed by three forms of estimation applied on each sub-task. 

The PERT technique applies the following formula: [Test estimate = (0 + (4 * M) + E) / 6] 

The above formula comprises the following variables: 

a) O: This variable denotes the ‘optimistic estimate’, which defines the best-case situation where everything runs as expected, and all conditions are optimal. 

b) M: This variable denotes the ‘most likely estimate’, which defines the most likely effort duration, including a few errors but with many successful runs. 

c) E: This variable denotes the ‘pessimistic estimate’, which defines the worst-case situation where everything goes wrong. 

Use Case Point or UCP method 

The Use Case Point is a method devised for calculating the unadjusted weights and use-case weights. These calculations help determine the estimation of the software test cases. The use-case is essentially a document specifying the various users, stakeholders, or systems that are interacting with the application in question.   

These entities are typically known as ‘Actors’. Now, the interactions between these actors are intended to accomplish a set of defined goals that protect the interests of all involved stakeholders through different scenarios.   

Benefits of Planning Poker 

Here is a list highlighting the various benefits of Planning Poker that encourage you to adopt them in your software application’s estimations: 

a) Planning Poker is a clear and precise estimation technique that is preferred by most software developers. 

b) Planning Poker encourages all team members to participate in the process of creating their estimations. Their active involvement allows them to better understand the user requirements and gain more experience along the journey. 

c) Planning Poker basically gives all participants the space to present their ideas about their estimations. 

d) Planning Poker supports user story points, which eliminate the differences among team members. 

Drawbacks of Planning Poker 

Here is a list describing the drawbacks of Planning Poker that are important to understand: 

a) Planning Poker is best suited for project tasks that are partitioned into small-sized tasks to fit a specific frame of time. 

b) Planning Poker can become a disputable process if participants are made to commit to a procedure that they would not have agreed upon in the first place, which can prove to do more harm than good for Agile teams. 

c) Planning Poker sessions is helpful only for weekly sprint sessions and for anything that is planned well in advance. 

Conclusion 

We hope that you now understand the concept of Planning Poker sessions in Agile environments. It is a very common Agile methodology that allows a team to calculate the estimates of time and effort necessary for a project’s delivery. It is beneficial to many organisations to help them deliver projects in a timely manner with minimal bugs. More importantly, team members are encouraged to actively contribute and interact with one another, fostering a collaborative environment and improving productivity. 

Harness user stories to create the best projects, by signing up for Agile User Stories now!