The Concept Of Agile Estimation
One of the most challenging activities for any project team is the User Story estimations, this is due to that estimations are expectations which is based mainly on experience and historical information, but the history doesn’t necessary repeat itself, especially in today’s uncertain VUCA (Volatile, Uncertain, Complex and Ambiguous) world,
In the past, before the rise of Agile mindset and practices, project teams used to depend on the time estimations and deadlines, this has proven to be ineffective and unrealistic in today’s business environment which is rapidly changing every day, hence cause frustrations to the business and the team which lead to overall tensions on the project, and sometimes misleading estimations in order to satisfy the business.
In Agile the concept of estimation is completely changed to be more convenient to the uncertainty we have, taking into account the team empowerment Agile is promoting for, so here is the main key aspects of Agile Estimations :
- The team won’t estimate times nor durations for completing the user stories, they will estimate the weight of the work which include (level of effort & complexity).
- The team will assign numbers which is called “Story Points”.
- These numbers are sequenced according to “The Fibonacci Sequence” which is 1,2,3,5,8,13,21,34, etc.
- The core idea of Agile estimations is to make relative estimations, which means comparing between the different user stories from the smaller size to the bigger size,
- For Example, if you have 5 user stories and the team wants to estimate these stories and assign story points, one of the approaches is to pick the smaller size story and assign it as “1” story point, this indicates the size of the story which is the level of effort and complexity of this user story, then the team would compare all other user stories to this one and assign story point based on Fibonacci numbers.
- So if the team felt that another user story is twice the size, then they will assign “2” story point to it,
- If there is another user story which is twice the size of the user story which sized as “2” they should assign “4” !!! no this is not correct, they should assign “5” story points as there is no “4” in the sequence, remember ?
- And so one, the team completes assigning story points to the user stories likewise.
I know that you have a question on your mind, what if the team doesn’t know exactly the size of the story, if the story is very new to the team and they have no history to rely on, that’s a good question 😊. This is part of the Agile estimation, the team should learn by experiencing, if the team doesn’t have history they should make the history, means they assign whatever points they think it’s relevant, then after the sprint they learn if the estimation they made are relevant or not.
The goal of the estimations is for the team to commit on number of user stories to be done during the sprint which is a specific period of time, the team has the utmost freedom to determine how they will develop the different stories and in which order, the most important point for the business is to get the stories promised and committed by the team, done by end of the sprint.
We should take into consideration that the team’s estimate mostly won’t be relevant in the beginning of the project, because they are learning by doing, it’s like if you are going to the Gym for the first time, and you thought you would be able to lift 20 Kilos by one hand, but when you try to do this you couldn’t and you figured out that you can lift only 10 Kilos, then the next time you go to the Gym you will set realistic expectations, and by time and commitment you will have more muscles to increase the weight, this is what happened with the team, by time and experience their productivity “muscles” will increase.
There are many estimation techniques to be used by the team, one of the most recognized ones is the “Planning Poker” estimation which is a consensus-based technique for estimating, It’s a way to make the estimation process more engaging and ensure that every team member’s voice is heard.
How It Works
- Preparation:
- The team has a backlog of user stories.
- Each team member has a set of Planning Poker cards with values that represent effort estimates (e.g., 1, 2, 3, 5, 8, 13).
- Discussion:
- The product owner presents a user story to the team.
- The team discusses the user story to ensure everyone understands it fully.
- Estimation:
- Each team member privately selects a card that represents their estimate for the effort required.
- All cards are revealed simultaneously to prevent bias.
- Consensus:
- If all estimates are the same, that becomes the estimate.
- If there are differences, team members discuss their reasoning.
- The process is repeated until the team reaches a consensus.
Benefits
- Encourages Participation: Every team member contributes their perspective.
- Reduces Bias: Simultaneous card reveal prevents anchoring to others’ estimates.
- Improve Accuracy: Discussion helps uncover hidden aspects of tasks.
Tips for Effective Planning Poker
- Clear User Stories: Ensure user stories are well-defined before the session.
- Time-Box Discussions: Keep discussions focused to maintain efficiency.
- Facilitator Role: Have a facilitator to guide the session and keep it on track which is mostly to be the Scrum Master
This method not only makes estimation more accurate but also fosters team collaboration and understanding.
In a nutshell, Agile estimation is a way to promote collaboration and ownership between team members, it’s not made to put extensive pressure on team members, it’s made to help team members to be more productive and aligned with the business objectives,
Having more questions on Agile Estimations, please contact us on support@vidscola.com.