Getty Images
Top 5 Agile estimation techniques
Stakeholders want development teams to stick to rigid timelines, which doesn't align with Agile development. These five Agile estimation techniques can help bridge the divide.
The terms Agile and estimations don't align perfectly. Agile is all about responding to change rather than following a plan, while accurate estimations require a fixed plan that doesn't change. It's a paradox that's hard to resolve.
However, even before the Agile Manifesto was signed, developers were already exploring ways to gauge the effort required to implement a feature, user story or task. Agile estimation is not an exact science, but to bring as much precision as possible, product development teams typically use one of the following five Agile estimation approaches:
- Calendar days.
- Ideal days.
- Story points.
- T-shirt sizes.
- No estimates.
Calendar day estimation
The simplest Agile estimation approach is to estimate how many calendar days, or half-days, it will take to develop a given feature.
Small teams composed of experienced developers working on projects with clear, stable requirements do well with this technique. It's simple and effective.
However, there is one important guideline: Estimated tasks shouldn't exceed five days. If the team estimates a task will take more than five days, they should break it down into smaller tasks. Estimating beyond a week increases the cone of uncertainty beyond acceptable limits.
Ideal day estimation
Ideal day estimation asks a developer to estimate the actual uninterrupted time they would need to complete a task -- essentially, an ideal day.
Once the ideal number of days is estimated, it's multiplied by a load factor to account for real-world interruptions, giving you the number of calendar days required for the task.
Load factors, often a multiple of three or four, account for time lost to factors such as the following:
- Context switching.
- Unnecessary meetings.
- Administrative tasks like emails.
- Changing requirements.
Ideal day estimations originated in early Extreme Programming environments. However, to avoid confusion between an ideal day and a calendar day, the term was replaced by story points, although story points have evolved beyond those roots.
Story point estimation
Story point estimation is the most popular Agile estimation technique. It focuses on effort rather than time, which can create friction with project managers who seek clear timelines.
A story point gauges the effort required for items in a team's product backlog. For example, a user story with two points should take twice as much effort as one with one point. An eight-point story should require four times the effort of a two-point story.
To help teams visualize effort, story points often follow a general mapping such as this:
- One point: half a day.
- Two points: one day.
- Three points: two days.
- Five points: three days.
- Eight points: one week.
When teams estimate a task as 13 points (the next Fibonacci number), that typically indicates unclear requirements. Break down the task into smaller, more manageable chunks.
To truly measure progress, a team shouldn't just focus on the points assigned but also its own velocity, or the number of story points typically completed in a sprint. By dividing the total points of an epic by the team's velocity, managers can roughly estimate the timeline for completion.
T-shirt sizing
The numeric nature of story points makes it tempting to convert them into time estimates or to compare teams across an organization. However, this corrupts their original intent.
To retain the spirit of story points while avoiding pitfalls, many Agile teams opt for T-shirt sizing.
This approach categorizes backlog items into the following five sizes:
- Extra small (XS).
- Small (S).
- Medium (M).
- Large (L).
- Extra large (XL).
T-shirt sizing allows teams to estimate relative effort without being constrained by tight deadlines or focusing on merely completing story points instead of delivering valuable features. T-shirt sizing is especially useful for new teams that have unknown velocity or capabilities.
The disconnection between T-shirt sizes and exact time estimates helps Scrum masters push back when managers ask for hard deadlines. It also fosters conversation. Large or extra-large stories signal to stakeholders that developers see significant risk or uncertainty in the requirements.
The no-estimate approach
The final Agile estimation technique that has gained traction is the no-estimate approach. This movement argues that estimations in an Agile environment are inherently unreliable, and it's a waste to spend time on estimation, whether through poker planning or T-shirt sizing.
Instead, teams should work on the most valuable user stories, deliver regular updates to stakeholders and prioritize creating a minimum viable product, followed by additional features. Estimates don't predict actual delivery dates, so there's no point in spending time on them. Build the product and let developers focus on development.
Estimating the effort to complete any task -- whether it's software development or building infrastructure -- is fraught with uncertainty. Product development teams can alleviate that uncertainty with several Agile estimation techniques.
The choice of technique depends on a team's stage in its Agile journey, how long team members have worked together and the maturity of the product under development. Experiment with each approach and find what works best for you.
Darcy DeClute is a technical trainer and Agile coach who helps organizations apply Scrum-based principles to adopt a modern DevOps stack. She is a certified Professional Scrum Master, Professional Scrum Developer and Professional Scrum Product Owner as well as author of Scrum Master Certification Guide.
