Time-tracking and Agile Reporting

Agile Coaches and Scrum Masters are steering their teams through an agile transformation, intending to shift from concrete time measurements to the more fluid concept of Story Points. They're looking to do this in a way that feels natural to the team by drawing on their well-honed abilities to estimate and adjust the time they spend on tasks.

One of the hurdles they face is that most reporting tools aren't designed to handle the actual time spent and the estimated time remaining simultaneously; they're set up to monitor just one metric. This limitation can obscure the team's true progress and velocity.

To tackle this, the idea is to use the team's time tracking as a makeshift version of Story Points. By merging the two types of data—time spent and time remaining—teams can continue using familiar tools while applying agile principles to track their performance. This blended approach can offer teams a more nuanced view of their workflow as they embrace Story Points, ensuring a smoother transition and more accurate forecasting.

How can time-tracking be used in tracking Burnup/Burndown and Velocity

First of all, let’s align on terms:

• The 'Remaining Time' (RT) field indicates the required time to complete the issue. This estimate is established during issue assessment and decreases automatically as work time is logged. This estimate can be manually adjusted if there are changes in the projected time needed.

• When resolving an issue, you can either 'zero' or 'not zero' the Remaining Time. If not zero, the estimate remains until an update in the Time Spent. To reset it to zero, a custom automation rule must be implemented to modify the field values.

• Burnup/Burndown charts illustrate the team's progress over specified time frames, like sprints or reporting periods. Burnup charts track the total completed work and any adjustments in the workload, while Burndown charts focus on the work left to do, showing the team's rate of progress.

• Velocity charts gauge the volume of work a team will likely accomplish in a forthcoming sprint or cycle based on their past activity. These charts offer a graphical depiction of the team's typical work pace, aiding in the planning and forecasting of future tasks and timelines.

Team/Cross-team Sprint Metrics

To understand how integrated time-tracking can be applied to track Completed Work by sprints, let’s examine the story of one issue in two sprints.

First Sprint: The issue started with an RT of 8 hours. During the sprint, 2 hours were logged as TS, which decreased the RT to 6 hours. By the end of this sprint, 2 hours of work are counted as completed.

Second Sprint: The issue rolls over with an RT of 6 hours. During the sprint, an additional 2 hours were logged as TS, after which the issue was marked as Done.

If the RT is zeroing, when the issue is resolved, the completed work in the second sprint equals TS of 2 hours because the team was very efficient in resolving the issue with less time spent than planned.

If the RT is not zeroing RT, the completed work is TS + RT at the end of the sprint, which is 2 hours + 4 hours = 6 hours because the team was productive in finding ways to resolve issues faster.

In conclusion, we recommend using integrated time-tracking for two purposes:

1. To Highlight Efficiency: Use zeroing of RT to focus on the actual time spent on the issue.

   1. If you don’t want to create a custom automation rule to implement RT zeroing but still need to count only Time Spent, switch on the toggle:

      

2. To Emphasize Productivity: Use not zeroing of RT to demonstrate the team’s ability to complete work relative to the original estimate.

Applied to

• Team/Cross-team Velocity chart for Scrum boards

• Team/Cross-team Burnup chart for Scrum boards

• Team/Cross-team Burndown chart for Scrum boards

• Team Burndown chart for Sprints

Interval Metrics

To illustrate how integrated time-tracking works in Kanban mode, let’s describe an example with a single issue over two intervals:

First Interval: An issue starts with an RT of 8 hours. During the interval, 2 hours are logged, reducing RT to 6 hours. By the interval's end, 2 hours of work are recorded.

Second Interval: The issue continues with an RT of 6 hours. An additional 2 hours are logged, and the issue is then marked as Done.

If RT is reset to zero upon issue completion, the second interval records 2 hours of completed work, reflecting high efficiency.

If RT is not reset, the completed work is 2 hours (Time Spent) plus 4 hours (Remaining Time) = 6 hours, showing productivity in issue completion.

In conclusion, integrated time-tracking is recommended for two key aspects:

1. To Highlight Efficiency: Use RT zeroing to emphasize the actual time spent on issues.

   1. If you don’t want to create a custom automation rule to implement RT zeroing but still need to count only Time Spent, switch on the toggle:

      

2. To Emphasize Productivity: Opt for not zeroing RT to show the team’s effectiveness in relation to the initial estimate.

Applied to

• Team/Cross-team Velocity chart for Kanban boards

• Team/Cross-team Burnup chart for Kanban boards

• Team/Cross-team Velocity chart for JQL filters

• Team/Cross-team Burnup chart for JQL filters
  

Personal Sprint Metrics

To understand how integrated time-tracking can be applied to track Completed Work by sprints on a Personal level, let’s examine the story of one Assignee and one Issue in two sprints.

First Sprint: After the sprint was started, the Issue was assigned to Assignee. The issue was estimated to have an RT of 8 hours. During the sprint, Assignee logged 2 hours as TS, which decreased the RT to 6 hours. By the end of this sprint, 2 hours of work are counted as completed by the Assignee.

Second Sprint: The issue rolls over with an RT of 6 hours. During the sprint, an additional 2 hours were logged as TS, after which the issue was marked as Done.

If the RT is zeroing, when the issue is resolved, the completed work by the Assignee in the second sprint equals TS of 2 hours because the Assignee was very efficient in resolving the issue with less time spent than planned.

If the RT is not zeroing RT, the completed work is TS + RT at the end of the sprint, which is 2 hours + 4 hours = 6 hours because the Assignee was productive in finding ways to resolve issues faster.

In conclusion, we recommend using integrated time-tracking for two purposes:

1. To Highlight Efficiency: Use zeroing of RT to focus on the actual time spent on the issue.

   1. If you don’t want to create a custom automation rule to implement RT zeroing but still need to count only Time Spent, switch on the toggle:

      

2. To Emphasize Productivity: Use not zeroing of RT to demonstrate the team member’s ability to complete work relative to the original estimate.

Applied to

• Personal Velocity chart for Scrum boards