Many agile and scrum teams start with basic practices to enable self-organizing teams to better deliver on business priorities. Practices include committing to what teams can get done in a sprint, holding daily standups to manage work in progress, hosting demos for stakeholders to showcase completed work, and organizing retrospectives to discuss process improvements.
Using these fundamental practices, small agile teams can demonstrate business value by delivering incremental improvements and enabling stakeholders to weigh in on new priorities.
As organizations and teams mature their agile practices they are often faced with new questions. Leaders might ask, “Can you tell me when the feature we prioritized will be done,” or “Can you share with me a list of features that are likely to be done over the next few months?” A product owner might ask, “How expensive and complex is this enhancement,” and the operations team might want to know, “Can you squeeze in these defect fixes in the next sprint?”
Teams that dedicate themselves to process improvement often have related productivity and quality questions around their agile process. Many agile tools measure team velocity, or how much teams can get done in a sprint, and teams will want to define, measure, stabilize, and ideally increase their velocity. More advanced teams often want to look at their overall performance across many sprints: Are they delivering higher quality when they work on lots of small stories, or just a few big ones? What’s the impact if a team member is out on leave for an extended period, or, what more can they take on if new people are added to the team?
What is agile estimation
If you are running into any of these questions, your organization or team might be ready to implement agile estimation. Agile estimation aims to assign a cost factor to everything in the backlog. This cost weighting can then be used to measure team velocity, make better decisions around feature prioritization, or use to develop forecasts and roadmaps.
There is some debate on whether implement agile estimation. There’s a movement around #NoEstimates and there are also experts who have weighed in on using estimates. If you are leading the charge on implementing estimates in your organization, it’s important to read through these arguments. Getting people to estimate isn’t easy, and you will likely find people who don’t want to participate. Understanding the debate will help you respond to team or individual suggestions or objections.
Agile estimation requires you to come up with a methodology on how a team should develop consensus on the estimate. You might hear about planning poker, the bucket system, affinity mapping, and other estimation techniques. In my work, I usually empower teams to decide how they will work together to come up with their estimates, but I do provide some guidelines. Estimates should reflect on the effort and complexity of the issue being worked on and should account for everyone’s work.
Estimating with story points versus hours
To give teams more concrete guidance on estimating, there should be a discussion and standard set for a unit of measure. Here again, there is some debate on whether to estimate in hours, an abstract measure called story points, or with labels like T-shirt sizes.
Some teams start with T-shirt sizing because it’s easier to understand and communicate. A size “small” is probably something that’s easier to do compared to an “extra large,” and teams, product owners, and stakeholders can reflect on these terms a little bit more easily compared to estimates of “ten hours” or “eight points.”
But using T-shirt sizes provides no quantification, so they are harder to use for measuring velocity or performing analytics. Many teams will graduate from T-shirt sizes as they mature their estimation practices.
Effort-hours are good metrics to use when teams are performing more standardized tasks that have low complexity or risk associated with them. Knowing that a story to modify the user interface will take two hours of effort is valuable if the type of task lends itself to an accurate effort-based metric.
But software development and other business processes are less precise, have more unknowns, and often require contribution from multiple people with different skills. If your story requires interfacing with a new API, developing a front-end widget, and ensuring the delivery meets targeted performance criteria, the story might be hard to measure in effort-hours. There’s risk in working with a new API, and there’s likely coordination between two or more people to implement the code and test cases.
Many teams use story points as a way to represent both effort and complexityin the estimate. A low story point indicates a low-complexity, low-effort story, whereas a high story points indicates both complexity and effort across the team. Many teams assign points based on the Fibonacci sequence so that increasing complexity and effort has an exponential increase in story points.
In addition, the best teams put some qualifying language around point assignments. For example, a team may qualify a three-point story for small changes or additions to the user experience that do not require any back-end or API changes. You can see that this qualification bounds the effort to probably one front-end web developer and the risk because the changes are being implemented only in the web tier.
Burndown charts and technical debt have additional meaning
It usually takes teams several sprints to normalize their estimating practices. But once done, there are several important ways to use them. Teams should start by optimizing their commitment and development processes by understanding their velocity and what blends of stories by type and size to commit. Teams should better understand how many small, medium, and large stories they can execute optimally. Many teams recognize the risk and coordination required to complete larger stories, so they commit to few large and many small stories in a sprint.
Sprint burndown charts that are available in most agile managements tools can now be weighted by the estimates and used to optimize work during the sprint. In addition, epic and release burndowns now have more meaning as they help teams focus on higher value and risk stories earlier in the development process.
For teams with automated CI/CD pipelines and more frequent releases, estimated stories become a valuable tool in deciding how to manage the development pipeline. Longer-running features may be better managed in feature branches, medium ones with feature flags, and smaller changes committed directly to the master development branch.
Last, teams can start measuring the magnitude of their technical debt. When debt is identified and captured in the backlog, an estimate should be assigned to the effort and complexity in resolving it. When teams add technical debt stories to their backlog and estimate proactively, they now have a measure of total technical debt. They can also report on how much technical is prioritized and addressed in every sprint and release. Since most development teams are passionate about the magnitude of their technical debt, using estimates to measure it is a good way to get the team onboard with an estimating process.
Using estimates to drive prioritization
Once teams have developed confidence in their estimates, they can then be used with product owners and business leaders. The first place to start is to develop a planning process that targets getting all stories for a feature written, prioritized, and estimated. Some organizations perform agile planning in parallel to their development efforts, while others develop a separate sprint cycle for planning. In my book Driving Digital, I share a two-stage process for story writing where “story stubs” are drafted and estimated in stage one and prioritized stubs are then fully written and re-estimated as stories in stage two.
Once a feature is estimated, the team can have a more data-driven discussion with the product owner on its scope and priority. Is Feature A with five stories and 35 points more important than Feature B with two stories and 12 points? Or maybe if the requirements for Feature A are simplified, it can lead to a reduced estimate.
When teams estimate multiple features in their backlog, it can also lead to better release planning and developing roadmaps with the product owner. Teams can review the type of work and sizes of stories and present options on what features can be worked on optimally for an upcoming release.
What should not be done with agile estimates
There are several places where using estimates is problematic. First is when organizations apply time tracking and want to compare the actual hours applied to a story compared to the estimate. This comparison doesn’t work well when estimating with story points because points often represent complexity and effort. Even when estimating in hours, teams are better off evaluating their delivery on commitments and ability to maintain or grow velocity rather than scrutinizing individual estimates.
Second is when managers try to do resource allocation using the estimates. They may suggest that a person on the team can take on more work because he or she has assigned fewer points than previous sprints. This logic is deeply flawed because agile teams don’t fully account for all team members’ participation on completing user stories. This form of resource management amounts to micromanagement, but that blocks the success of agile teams, which is built on trusting teams to make honest commitments.
A similar issue is if managers try to use assignments and estimation to gauge individual performance. Again, the estimates and assignments teams make while managing their priorities is not the best tool for reviewing individual productivity.
All that being said, today you’ll find more teams using agile estimation as a way to improve team productivity, quality, and business alignment.