Estimating Tasks in Azure DevOps
Tracking the time on tasks is a common way to show the burn down of work during a sprint.
Remaining Work
In Azure DevOps this is done using the Remaining Work field on the task work item. This field has been added to the task in all four process templates. (Basic, Agile, Scrum and CMMI)
Note: In the Agile template the label for this field is Remaining. In the other three templates (Basic, Scrum and CMMI) the label is Remaining Work. It’s the same field in all cases.
This field is used for many things in Azure DevOps, including:
Original Estimate and Completed Work
The Remaining Work field is useful to understand how much work is left to do.
However after the sprint is over, can we tell how long it really took, and how well we estimated it to start with. We do have each rev of the work item so we could see how the user changed the Remaining Work field over time. However this is not so easy to query. Plus it really just shows each time the Remaining Work field was changed.
The Agile and CMMI templates have two fields on the task that I have found to be very useful. Specifically when it comes to looking back at past sprints. The fields I am referring to are Original Estimate and Completed Work.
These two fields can be a great source of information when used correctly.
Consider this timeline of events as an example.
- Upon creation the team estimates how many hours it will take to complete the task and enters those hours in the Original Estimate and Remaining Work, Completed Work is of course zero at this point in time.
- Day 1 — If we spend two hours on this task, we would change Remaining Work to 4 and set Completed Work to 2. The change to Remaining work is feeding the burn down sprint capacity and rollups. We’ll use the Completed Work field later. The Original Estimate should never change once the task is in progress.
- Day 2 — Lets assume we come across something we didn’t think of, and realize it’s more work than we originally thought. The original estimate is now wrong. However instead of changing that, lets record that we spent 2 hours working on it by adding 2 hours to the Completed Hours field, and set the Remaining Work to what we now think is left to do.
- Day 3 — We spend 3 hours working on the task. So Remaining Work goes down by 3 and Completed Work goes up by 3.
- Day 4 — We complete the task after 2 more hours of work. Therefore we’ll add 2 to Completed Work. Remaining Work will be cleared when we change the state to Done.
Having everyone fill in these 3 fields on a task like this, means we have some extra data to work with.
Reporting
Using Power BI we can pull together two small tables of data. One with all the Backlog Items and the other with all the child tasks for each sprint. By creating a relationship between the two tables using Parent Work Item Id on the task and the Stories Work Item Id. We can roll up the task fields on the Story.
Now we can pull all this together and organize by Sprint and Story. Azure DevOps Analytics has some other useful data including Lead time (Days from inception to completion) and Cycle Time (Days from Starting work to finishing). I am including these in the report as they are good metrics to go along with the size of the story and the estimated and actual hours to complete.
During a Retrospective or backlog prioritization meeting the team can look back at stories in past sprints and quickly see each stories Lead Time, Cycle Time, Estimated Hours and Actual Hours, as well as the size they assigned to the story. Let me just say, I am not advocating associating time with Story Points.
Note: In Azure DevOps Story Size is normally entered using:
- Effort on the Issue in the Basic template.
- Story Points on the User Story in the Agile template.
- Effort on the Product Backlog Item in the Scrum template.
- In the CMMI template you would need add one of these to the Requirement, it is not there out of the box. Which makes sense, if you are using Story Points you are likely not using CMMI.
However getting all this data into one place can be insightful.
Patterns begin to arise, in my experience teams begin to see things they never thought about before. Also when trying to estimate a story, being able to look back at a similar story and see this information can help with the current estimate.
Also once we have this we can slice the data in other ways. Examples: by Activity, Assigned To or Value Area.
Rules
You may want to update the process template by adding some rules to the Original Estimate field, to ensure it gets used and to make sure no one changes it once the task is in progress. In your inherited process open the Task work item type and go to the Rules.
I hope this was helpful for a team using Azure DevOps looking to get some insights into how well they estimate.
Basic and Scrum Templates
As I mentioned earlier the Original Estimate and Completed Work fields are not included by default in the Basic and Scrum Templates. So if you are using one of these templates and want to use these fields you will have to add them to the task in your inherited template.
If you have never done this before here is some info. Although it’s pretty easy, here is an abridged version of the steps to do this.
- Go to Org Settings -> Boards -> Process
- If you don’t already have an inherited Process you will need to do this next step first, to create one.
- Click on the ellipsis next to the process you want to customize and select Create inherited Process, give it a name and description and click create process.
- Once you have the inherited process, open it, and under Work item types select the Task.
- In the task editor click New field to add the Original Estimate field. Remember the field already exists all you are doing is adding it to your process.
- Under layout you can decide where to put it on the task form.
- Follow the same steps to add the Completed Work field.
Existing Projects
If you have an existing team project that previously used the Scrum Template. There is one more step.
- Go to the Scrum template and select the last tab “Projects”
- These are all the projects that use the Scrum Process. You can change their process to your new inherited process form the ellipsis.
