User story estimation in Azure DevOps can often be a confusing process for users, especially those new to agile. Out of the box, Azure DevOps attempts to reconcile estimation in hours with story points. User story estimation can be a contentious topic among agile circles anyways, so this inconsistency between hours and story points in Azure DevOps often creates more problems than solutions. To combat these issues, I've developed an approach to drive accurate and consistent user story estimation in Azure DevOps, which I have successfully applied across multiple agile teams. This has led to sustainable delivery velocity and a high degree of confidence in forecasting and predictability.
Estimating Level of Effort
Estimating level of effort in software engineering has plagued individuals and enterprises for decades. Software engineering is a subjective process and there are often many unknowns when attempting to estimate effort. Any good agile coach will tell you that the only way to estimate level of effort is to apply the abstract concept of story pointing, which has no basis in time or team capacity, but is instead based on the perceived complexity of delivering a requested feature. From the managerial perspective though, budgets beget deadlines, which drives the need to derive objectivity from subjective practices.
In my experience, developers tend to underestimate the effort required to deliver working software. They typically only consider writing code and often overlook tasks such as testing, validation, corrections originating from pull requests, QA improvements, deployments, etc. Developers also just want to write code, not spend time performing administrative tasks, but when budgetary constraints and overwhelming demands are the norm, teams must be capable of articulating the true effort required to deliver working software. Creatively leveraging Azure DevOps can help to solve this problem.
Inconsistencies in Azure DevOps
The default configuration in Azure DevOps assumes that team efforts are based on time - tasks specifically caption effort with the word “hours”. User stories also display effort based on the sum of remaining time on child tasks, and story points are tracked as a separate field. This juxtaposition of remaining time and story points is a major pain point for many teams and can create quite a bit of confusion in agile adoption overall. If hours do not equate to story points, why does Azure DevOps attempt to correlate the two? In the example shown here, how does 17 hours equate to 5 story points?
A Different Approach
In order to bring consistency to user story estimation and strike a balance between story points and team capacity, teams must take a different approach. The premise is simple – disregard hours and estimate tasks based on fractional days of effort. This enables user story level of effort to be validated against task estimates which correlate to sprint length and team capacity. This approach adds just the right amount of abstraction to empower teams to more accurately estimate and plan work.
To begin, teams must agree on several key points:
- What is the sprint length and what is the basis for story points?
- What is the maximum story point velocity that a single developer can deliver per sprint?
- What is the maximum size of a single story and when is it too large?
To keep things simple, my teams work in two-week sprints and our story point basis is 1 with a maximum story point velocity of 10 story points per developer. In terms of time, this means that a story point could be delivered in about one day, give or take. We estimate stories based on the Fibonacci sequence and agree that any story larger than 8 story points likely needs to be broken down into smaller units.
Azure DevOps Workflow
The first thing to do in Azure DevOps is to break down user stories into tasks in Azure DevOps boards. The idea here is to account for every task necessary to deliver the associated user story, including corrections from code review, QA review, deployments, validation, documentation, etc. In the example here, I’m outlining the child tasks associated with a user story that defines a new customers micro-service featuring a search endpoint. In general, the goal is to group similar units of work into common tasks that accurately detail the required steps without creating undue administrative burden.
After stories are broken down into individual tasks, they can be estimated in terms of fractional days of effort represented by decimal values. The key here is to never estimate a task below .25 or above 1. Anything estimated below .25 causes teams to underestimate the total level of effort at the story level while anything over 1 indicates that a task is not broken down into enough detail. It’s also important to keep tasks limited to 1 day or less so that the team is able to show forward progress every day - the psychological impact of moving a card every day is a powerful motivator.
The next step in the process is to validate your story point estimate against the total sum of all estimated tasks. By default, Azure DevOps displays the sum of estimated child tasks in the the Remaining Work field on the user story, which is can be viewed in the Sprint Taskboard or Backlog views. In the example below (viewed from the Sprint Backlog), I now see that the remaining work on this user story totals 3 days, but my user story is only estimated at 2 story points. Considering that an engineer can complete a maximum of 10 story points per sprint, and I’m estimating 3 days of effort, this user story should likely be 3 story points. By following this approach, I am now able to more accurately estimate story points and bring some consistency to the process.
The final step to complete in Azure DevOps is to plan developer capacity per day in terms of story points instead of hours. This simple change will help teams visualize their sprint burndown based on story points instead of total estimated task hours or count of work items - delivering user stories is the true measure of sprint progress anyways. In this example, I’m setting developer capacity per day to 1, which represents 1 story point per day.
While this approach may not work for every team, it’s the best method I’ve found for reconciling story points with man hours, making it far more easy to estimate, plan, forecast and deliver software in an agile environment.