Developing a modern software application is a difficult task that requires planning, technical knowledge, testing skills, programming experience, and teamwork. Nowadays, developers use many different skills, tools, and programming languages to create the best MVP (Minimum Viable Product) possible.
In the planning stage, the development and QA teams gather to assess how much effort each update or feature needs. However, if planning meetings aren’t conducted properly, the development and QA teams may commit to more work than feasible.
This can leave many tasks unfinished by the end of the sprint. Fortunately, there is a powerful method to measure the effort required to deliver a software product: The Poker Planning Method.
What is The Poker Planning Method?
Poker planning helps measure the difficulty of a task and estimate how much time we need to complete it. Before further explaining, I have to give you a disclaimer: measuring task difficulty always depends on the experience and abilities of the project’s team members. I’ll add more detail later, but please keep this in mind.
The poker planning method uses the Fibonacci sequence, a sequence of numbers in which each element is the sum of the two preceding it. Starting from 0 and 1, the first few values in the sequence are:
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144,…
With poker planning, each team member can use numbers from the Fibonacci sequence to indicate how much effort a specific task or user story requires. We attribute lower numbers with less work and higher numbers with more work. So, a 1 means the task is very simple, and a 21 means the task requires a lot of work.
The entire team also has a velocity attribute that measures how fast the team finishes new updates and features per sprint. A team’s velocity is used to ensure that the team doesn’t take on more work than what can be done in a single sprint.
Who uses The Poker Planning Technique?
Regardless of their particular role, everyone on the team can use poker planning during the planning meeting. Though, members of the development team often find it easier to estimate the effort needed for a task as they make the most direct contributions to a new feature or update.
But what about the QA team? How does a QA engineer, analyst, or tester determine how much effort a task requires?
From previous experiences working on projects with many clients and teams of varying expertise, I’ve determined several reliable indicators of a task’s difficulty.
How to use The Poker Planning Method
Below, I will explain the criteria I use for each number in the poker planning method.
1 – Extremely simple task: No data persistence. No data processing. No integration between components. One-person testing effort.
Number one indicates that a task is very simple. For example, we consider updates that involve changing some wording (a text label) on a webpage, modifying some colors, or adjusting the sizes of existing components to be a 1.
2 – Simple Task: Data persistence required. No data processing. Possible integration between different components. One-person testing effort.
I usually give the number two to simple tasks in which information must be maintained throughout a multi-step process. For example, in-home banking transfers, the user must select specific details that will serve as input for the next steps in the process.
The software must maintain that information throughout multiple stages. In these situations, there is no data processing required, so it’s still a relatively simple task.
3 – Medium Task: This may require data persistence. Basic data processing. Integration with other components.
The task may require some data masking or obfuscation for security (but no encryption is required)—a substantial effort for one person to test.
Threes indicate operations whose outcomes depend on our initial product request choices, such as asking for bank credit or subscribing to a mutual fund. In such processes, we must cover multiple scenarios with our tests and integrate components on different levels. So, we need an experienced tester or analyst to figure out how to test each component fully.
5 – Hard Task: Data persistence required. Complex data processing. Integration with other components. Integration with other organizations or companies. Data encryption is needed—a two-person testing effort.
Fives refer to processes that require integration with third-party components, such as VISA, Western Union, or DHL. Credit card processing, for instance, involves sending a request to an external company that processes the operation. If the credit card information is invalid, the software receives an error message and must respond appropriately.
Other examples include testing chemical content for an industrial process our company operates. The software must ensure the accuracy of the request to avoid mistakes and to receive the expected response. For cases requiring a specific knowledge base, QA analysts or testers should ask their company for specific training to ensure they can accurately validate the software’s outputs.
8 – Expert level Task: Data persistence required. Complex data processing. Integration with multiple components at different levels. Collaboration with other organizations or companies. Data encryption is needed—a three-person testing effort.
Eights indicate a process requires extensive effort. The update involves different stages of information processing, some requiring integration with other companies. Multiple teams must communicate and work together to complete the task. Also, there could be different methodologies between the third parties and our own workflow.
For example, if a third party uses the Waterfall methodology and we work under an Agile method, we may experience delays in receiving the features we need to test. Since we’re working with insider information between companies, we must also encrypt our data to prevent legal conflicts and hacking. Eights require at least three experienced QA analysts and engineers.
13+ – Epic stories. A task that is impossible to complete in one sprint. Atomization and slicing techniques are required.
Any number greater than eight means a task requires tremendous effort. We call these tasks epic stories, divide them into parts, and finish them across multiple sprints.
Once we split the story, each part should be assessed again to determine if they require further atomization or slicing. This process should be repeated until we reduce the story into tasks we can complete in a single sprint. No epic stories should be allowed into the sprint.
The Takeaway
Following these guidelines, teams can plan sprints more effectively. However, estimations will always depend on the skills and expertise of a project’s team members. If your team is new to the company or the development methodology, then you should overestimate the effort required for their tasks.
New team members may understand a project’s requirements, but they may lack experience with the particular skills needed to complete their work. First times are always hard, but we can plan accordingly if we keep this in mind.
Here at Rootstrap, the QA team wishes you the best always! Feel free to let us know your thoughts in the comments section.
