Article summary
The Remaining Work field in Microsoft’s Azure Boards is usually talked about in the context of burndown charts. But if you are in a scrum master role and have more than a few developers on your team, you might find the Remaining Work field useful for helping you coordinate work.
What Is “Remaining Work”?
You can find the Remaining Work field on a backlog item’s child task(s). It is intended to indicate how much work is left to be completed on the task. The field will take a full or partial number. Teams can reflect the duration necessary to complete the task by entering the number of days, hours, or minutes into this field. A summary of the Remaining Work associated with all tasks is rolled up and displayed on the parent item.
Where to Find It
On the sprint task board:
- The rollup of Remaining Work displays on the parent work item.
- The sum of all Remaining Work defined for all items within a column displays at the top of each column.
- The sum of all Remaining Work defined for all tasks for a backlog item displays within each row, grouped by column.
There’s also an option to add Remaining Work to the backlog board. Once that field is added, the sum of all Remaining Work is displayed in the column for each parent item.
How We Use Remaining Work
Our project team consisted of a dozen developers across two countries and four timezones. When we began, we figured one of our biggest challenges would be coordinating work, so we set a goal to keep all of the developers unblocked, not waiting on dependencies.
We experimented with using Remaining Work to help us coordinate work across our distributed team. In theory, developers could look across the sprint board to see when a story they were interested in was going to be completed. Having visibility into Remaining Work allowed them to know when an item assigned to them would be unblocked.
We tried to keep the process for entering Remaining Work simple. The field was populated by the assigned developer once a parent story was broken into its child tasks. Each developer working on a task was responsible for keeping the Remaining Work field updated.
What We Learned
Overall, the benefits of having visibility into Remaining Work were worth the time it took the team to keep the numbers updated. We learned several things along the way:
- It takes more than a few reminders to get everyone in the habit of populating and updating the field.
- Remaining Work numbers are estimates that get more useful as the work nears completion. When starting work on a backlog item, the developer populates the field with an educated guess. That number becomes more useful once the work is underway and the true picture of effort involved is understood.
- It can be easy for developers to spend too much time inputting Remaining Work. Just like when teams estimate levels of effort and/or story points, it’s tempting to want to scrutinize the estimation. We decided that keeping track of our overall team velocity was more important than pouring over estimates.
- It’s not useful to compare Remaining Work estimates with the actual time it takes to complete backlog items. If our estimates were far off, we chose to lump that into our velocity discussion during our sprint retrospective.
- Knowing the Remaining Work for individual tasks and the entire sprint becomes most useful on the last or second-to-last day of the sprint. Knowing the Remaining Work in the current sprint helped us predict how much of the next sprint would be spent finishing work in progress.
Azure Boards is loaded with layers of complexity. It can feel like there are so many features of this system that it becomes excessive to use most of them. However, the Remaining Work feature proved to be helpful when coordinating work across our distributed team.