Agile estimation techniques
Agile methodology is a set of strong organisational tools, including templates to use at different levels of product development. These tools include the agile project plan template, release plan template, sprint planning template, roadmap template, and the user story template.
What are the benefits of agile estimating and planning?
Both agile estimating and planning are key techniques in Agile project management, particularly in software development projects. They enable project managers to forecast with predictability, reduce risk and manage expectations of stakeholders.
Agile estimation forecasts and calculates the required effort to complete product backlog items according to their prioritization and business value. Understanding the time needed to complete a task, enables more accurate sprint planning.
These estimates define the aspects to consider during release planning. They establish the timelines for the release and the duration of the Sprint.
What is the difference between planning and estimation?
Mike Cohn, author of Agile Planning and Execution, says, “Agile planning balances the effort and investment in planning with the knowledge that we will revise the plan through the course of the project. An agile plan is one that we are not only willing but also eager to change.”
Planning is all about forecasting and preparing whereas estimating involves focussing closely on specific variables like scope or schedule. For example, you might estimate the time required for a particular task. As agile plans are flexible, iterative change is an essential part of this lifecycle. These changes mean that new estimates may be required. Cohn also advocates the use of buffers with estimates to allow for uncertainty (ie extra time in case of unforeseen events).
What are the 3 levels of agile planning?
Agile project estimation evolves on 3 levels:
- the project or proposal
- the release, which includes the assignment of story points taken from user stories
- arrival at the sprint level, where tasks and estimated hours required to complete them may be assigned according to complexity.
Agile story points estimations
Story points estimations enable a comparative analysis of development team goals. Addressing the relative size of product backlog items, the process of estimating user stories engages the entire team, including the product owner, scrum master, and other stakeholders.
A story point is used in Agile software development projects to estimate the difficulty of implementing a particular user story. Teams spend time initially making a schedule, planning out tasks and deliverables, and then they break down each one, estimating hours and costs. The amount of story points completed per iteration determines a team’s velocity.
Estimation follows 3 steps:
1. the team analyse the user stories and define the story
2. team members and facilitators pick and discuss stories from the product backlog
3. the agile coach or scrum master lists items to be addressed in sprint planning and the iteration planning of the software project.
An alternative metric to story points is ideal days. Team members explain their ideal day spent on the agile project, drawing on case studies and known dependencies, to determine the time required to complete tasks.
Key Agile estimation techniques for constructing Agile story point estimations
The original Agile Manifesto, the basis of Agile methodology, didn’t clearly define planning and estimation. Consequently, an estimate could just be a guess. In 2005, Mike Cohn developed agile planning techniques to help improve the estimation process and ensure that estimates were educated guesses at least. Planning poker was one of these techniques.
Planning Poker
Poker prep
Poker is easily adaptable to the energies of a small team. It’s one of the most popular agile estimating and planning techniques. The game encourages engagement and produces fast results. It’s inclusive, gaining input from testers, analysts, software developers, and other team members.
To start the poker prep, everyone involved in story estimations gathers in a circle. Next, the product owner reads a user story to the circle. The story will fully describe product features, user requirements, and stakeholder expectations. Story told, discussions among the estimators and the product owner give everyone a chance to ask questions and clarify development targets.
Playing poker
To set up the poker game, each estimator-player holds a set of Planning Poker Cards. Each card shows a numerical value to assign to the user story: 0, 1 ,2 ,3, 5, 8, 13, 20, 40 and 100.
After discussing the user story, each team member estimates the value of the story points by selecting the card that represents that value.
If all estimators select the same value, that becomes the final estimate. If the poker players select different values, those who assigned the highest and lowest values explain their choices. Discussion follows until an agreed re-estimation is found.
T-shirt sizes
Estimating size is a fast and useful way to reach a rough idea of requirements for large numbers of items in a product backlog. This is a great technique to ensure coordination between scrum teams working concurrently. It’s easy to visualise. However, one person’s L may be another’s XL as you’re not dealing in specific metrics (like Tshirt size in centimeters). Large or extra-large stories are known as epics.
Team members start with a discussion of the parameters to define ‘medium’. Then, each estimator on the scrum team assigns a size to the selected backlog item. The final estimate is the consensus reached after discussion and re-estimation of all size mismatches.
Dot voting
Dot voting is an estimation process used to rank product backlog items from highest priority to lowest. To start, all user stories and their descriptions are written on yellow sticky notes and posted to a board. Armed with dot stickers, pens, or markers, each stakeholder ranks the user stories. The product owner then orders the product backlog items from highest to lowest priority — from most to least dots. If there are stakeholders who disagree with the ranking or voting, user stories are separated into high, medium, and low-priority groups. Voting continues until prioritisation agreement is reached among all stakeholders.
Bucket system
Estimating work using the bucket system is faster and more flexible than planning poker for a large team grappling with a large number of items from the backlog. To begin, buckets — cards arranged on a table — are assigned values 0 to 5, 8, 13, 20, 30, 50, 100, 200, or more if required. Each product backlog item is written on a card and placed in the bucket selected by each estimator. Discussion continues until consensus on the whole product backlog is reached.
Affinity mapping
For small software development teams or start ups working with a relatively small number of backlog items, affinity mapping is a good bottom-up estimation method. Silently, team members have a go at estimating size.
Without group discussion, the product owner provides a list of backlog items to the team. Team members rank each item as smaller or larger and place them under cards on a wall. Discussion begins and the team may edit the wall, placing product backlog items appropriately, using T-shirt sizing or a Fibonacci sequence in the decision-making work. Finally, they reach a size estimation of the items.
An Agile approach is the through line
Agile methodology is the through line from proposal to product delivery, and agile estimation techniques define the agile project. These tried and tested techniques are essential to planning and project/ product management. It determines the scope and amount of work the agile team must complete to implement, test and deliver the product on time to the customer.
Learn more about agile estimating and planning with our Agile Training courses from Leadership Tribe today.
