Poker time

Hey Hive Brain,

Last week we talked about the complexity of Planning in Agile projects, As a professional in the field of Agile project management, I understand the complexity of planning in Agile projects and the importance of effectively communicating and executing these plans within the team. In this article, I will delve deeper into the specific steps and techniques used in Agile planning, starting with the Roadmap grooming ceremony and continuing through sprint and release planning.

First, it is important to note that after the Roadmap grooming ceremony, led by the Product Owner, all user stories must be clearly defined and made visible to the entire team. This is step one in the planning process; We must make sure they are visible to the entire team! – step -1.

Next, during the sprint planning ceremony, led by the scrum team, the team selects user stories from the backlog (a prioritized list of stories) to tackle during the sprint. It is important to keep in mind that determining the relative complexity of a task is often easier than figuring out how much time it will take, which is why the "moving car analogy" is commonly used.

How do they do that? 

As I have emphasized before, it is easier to determine the relative complexity of a task rather than figuring out how much time it requires – Moving car analogy.

The Teams discuss the requirements and functionality that each user story requires, in this point in time we have the option to adopt the concept of "2 heads are better than 1", it is an opportunity to get technical and creative in the team’s implementation of the story, if and once agreed upon, these requirements are added to the story.

Because estimations are uncertain by definition another common step in this meeting is to score the stories based on their complexity or time to completion. It is commonly used to handle this situation by taking the estimations into a "funnel" where there are multiple layers and with each layer, we go into the funnel with less uncertainty we have. The further out the estimation, the more inaccurate estimations get.

For the first highest level of the funnel where it is the widest and the unknowns are many, Teams should use t-shirt sizing scoring where we are examining the stories relatively between them and decide which one is the largest, which one is the medium one and which one is the smallest of them all. Obviously, you can use a wider scale, but I recommend keeping it as simple as possible.

After agreeing on the relative sizing, we should look at the stories on a more detailed level and try pointing them in Fibonacci numbers using games such as planning poker to make proper consensus on estimations.

Game of Planning poker process:

1.      The Product Owner sits down with the team to estimate the user stories.

2.      Each member estimates a number on the Fibonacci scale that he/she believes represents the size of the task. - Giving each member the opportunity to think individually reduces pressure and may result in a more accurate representation of the feature's size.

3.      All members disclose their numbers at the same time (to avoid being influenced by each other's estimates).

4.      Any differences in the numbers will be followed by a discussion until a consensus is reached.

5.      Each user story is added to a bucket that represents the corresponding point on the Fibonacci scale.

6.      The steps above are repeated for all user stories in the sprint.

7.      The buckets are added to the backlog.

shall we try to create a list of Fibonacci to use in our next estimation game?

0 – No business value, no significant effort is required to develop this story

1 – Petit; Scrum team understands the requirements and considers them relatively easy to develop, smallest item in the sprint is estimated up to 1 day of work in a sprint. some of the retrospective action items (Read the previous article about the Agile retrospective ceremony) could be considered as such.

2 – Small; requires problem solving or additional thought is required but it is a known tertiary where the team has the confidence of delivering it by requirements.

3 –Medium; a well know task that the team has done in the past perhaps several times, no additional research is needed to complete this story.

5 –Large; Complex work that the team does not usually done, will need to have high maintenance and will require additional help from other scrum personas to complete the story.

8 –XL; this story requires a Spike, a deep study probably more than a sprint just to wrap the head around it all.

13 -XXL; A lot of unknowns and must be considered, one way is to handle this story during multiple steps to reveal the assumptions another way is to divide the unrelated work into multiple teams that will work in parallel to complete this XL story.

21 -XXXL; Not possible to do in one sprint need to calculate a version that accommodates multiple sprints into one release.

As the team goes through multiple sprints and the estimation process is improved, the product manager can determine a stable velocity. The velocity is determined by calculating the number of story points completed in each iteration.

Once we have the estimations for the stories the entire team together with the Product owner can now assemble the story point of the stories into the sprint.

In conclusion, effective Agile planning involves clearly defining and communicating user stories, determining the relative complexity of tasks, and using tools such as t-shirt sizing scoring, Planning Poker, and Fibonacci numbers to accurately estimate and execute plans within the team.