Tracking Work Remaining Vs. Work Completed

Defining Work Tracking Metrics

Two key metrics for tracking workload progress in software projects are Remaining Work and Completed Work. Remaining Work refers to the total effort left to reach project completion. This includes all outstanding items across features, components, and other work units that the team still needs to implement before delivering the software. In contrast, Completed Work is the total effort already expended on the project so far. It encompasses all implemented features, components, user stories, or other work units that the team has already built and usually tested as well.

Teams can use various measures to quantify Remaining Work and Completed Work, such as story points in agile methodologies or ideal days in more traditional planning techniques. Regardless of the exact tracking mechanism, systematically monitoring these two metrics helps assess progress toward milestones and the overall project timeline. Comparing Remaining Work versus Completed Work also provides insights into the project pace and burn rate as teams progress through the development lifecycle.

Setting Up Tracking in Project Management Tools

Modern project management tools such as Jira and Azure DevOps provide built-in support for configuring boards, workflows, and reports to track Remaining Work and Completed Work. In Jira, admins can customize board columns across the full development lifecycle along with transitions between columns to match team practices for work item progression. These help quantify Remaining Work scoped into sprints or milestones and Completed Work transitioned to testing or release status.

Alternatively, Azure DevOps enables configuring swimlanes on Kanban boards to map states from New or Active to Resolved or Closed. The underlying work item types can include original effort estimates that translate into Remaining Work as well as logged completed hours for Completed Work. Teams can further analyze tracking metrics through burn-down charts natively available within Azure DevOps to visually gauge work status.

Monitoring Work Status Visually

Burn-down charts provide an effective visual means to monitor Remaining Work across sprints or milestones. They plot the total initial scope on the vertical axis while the horizontal axis represents timeframes like sprints or calendar weeks. Teams update the chart after each sprint to show work items completed, with the curve depicted towards the bottom of the chart over time.

In contrast, cumulative flow diagrams track Completed Work by plotting the status of all items based on the number that have transitioned to defined workflow states. For example, separate lines can represent items in specification, implementation, testing or done status. This helps assess throughput and cycle times across the development pipeline without emphasizing Remaining Work.

Sample Code for Custom Progress Tracking

For additional flexibility around work tracking techniques, teams can create custom metrics using sample code snippets. A simple Python script can calculate percent completed as the count of finished items divided by total items. This can be represented visually using a progress bar plot from the Matplotlib library. Alternatively, one can build a JavaScript widget to display the percentage completed updated programmatically by consuming status from a back-end service managing the work board.

import matplotlib.pyplot as plt
 
total_items = 100
completed_items = 50
  
percent_completed = completed_items/total_items*100
 
fig, ax = plt.subplots()  
ax.bar(1, percent_completed)
ax.set_ylabel('Progress') 
ax.set_ylim([0, 100])
plt.show()

  <div id="progress"></div>
   
  <script>
     let completed = 50;
     let total = 100;
     let percent = Math.round(completed/total*100);

     document.getElementById("progress").innerHTML = 
       `${percent}% Complete`; 
  </script>  

Keeping Track of Work Items in Agile Sprints

Agile frameworks designed for rapid iterations rely extensively on tracking progress both during and at the end of sprints. Scrum teams focus on accounting for all items committed at sprint planning by updating completion percentages as development work gets underway. Traditional daily standups provide a forum for teams to call out any roadblocks on unfinished work. Subsequently, sprint reviews offer more formal milestones to tally up items coded, tested and validated versus the original sprint forecast.

By continually reconciling Remaining Work and Completed Work at sprint boundaries, agile teams build empirical data on actual versus planned velocity. These metrics feed into more accurate forecasts for subsequent sprints based on the recent development throughput. Over longer horizons, the release burn-up chart trends total story points logged so far to project, enabling product and engineering leads to assess scope increase or creep.

Continuous Tracking for Predictability

Accurate tracking of Remaining Work versus Completed Work serves as the foundation for data-driven predictions of timeline and budget required to culminate development. Predictability enables stakeholders ranging from project managers to customers to set reasonable expectations on project closure. Unexpected issues will invariably crop up over longer development lifecycles to offset initial predictions. These can include technology changes, hosting limitations, vague requirements or staff turnover among other factors.

To maximize predictability in the face of known unknowns, agile teams rely on continuous tracking to periodically re-baseline projections. By empirically incorporating changes based on recent development history, they can re-plan remaining milestones or release dates backed by actual metrics versus speculative estimates. This closed feedback loop centered around tracking improvements culminates in more precise projections of delivery timeframes.