Using integrated Time Spent & Remaining Time
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:
To Highlight Efficiency: Use zeroing of RT to focus on the actual time spent on the issue.
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:
To Emphasize Productivity: Use not zeroing of RT to demonstrate the team’s ability to complete work relative to the original estimate.
Metric | Definition | ||
---|---|---|---|
Initial Commitment | The sum of RT(start) of all issues added to the sprint before the start date | ||
Final Commitment | The sum of RT(start) of all issues in the sprint after the end date + Estimation Change | ||
Added Work | The sum of RT(start) of all issues added to the sprint after the start date | ||
Removed Work | The sum of RT(end) of all issues removed from the sprint | ||
Estimation Change | TS + RT(end) - RT (start) | ||
Not Completed | The sum of RT (end) of all not completed issues in the sprint after the end date | ||
| In Progress | Completed: Toggle off | Completed: Toggle on |
Completed (Initial) | The sum of TS of all issues added to the sprint before the start date | The sum of TS + RT (end) of all issues added to the sprint before the start date | The sum of TS of all issues added to the sprint before the start date |
Completed | The sum of TS of all issues in the sprint after the end date | The sum of TS + RT (end) of all issues in the sprint after the end date | The sum of TS of all issues in the sprint after the end date
|
Applied to
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:
To Highlight Efficiency: Use RT zeroing to emphasize the actual time spent on issues.
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:
To Emphasize Productivity: Opt for not zeroing RT to show the team’s effectiveness in relation to the initial estimate.
Metric | Definition | ||
---|---|---|---|
| In Progress | Completed: Toggle off | Completed: Toggle on |
Completed | The sum of TS of issues for which time has been logged during the interval | The sum of TS + RT (end) of issues for which time has been logged during the interval | The sum of TS of issues for which time has been logged during the interval |
Applied to
Individual Sprint Metrics
To understand how integrated time-tracking can be applied to track Completed Work by sprints on a Individual 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:
To Highlight Efficiency: Use zeroing of RT to focus on the actual time spent on the issue.
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:
To Emphasize Productivity: Use not zeroing of RT to demonstrate the team member’s ability to complete work relative to the original estimate.
Metric | Definition | ||
---|---|---|---|
Initial Commitment | The sum of RT(start) of all issues assigned to the user and added to the sprint before the start date | ||
Final Commitment | The sum of RT(start) of all issues assigned to the user in the sprint after the end date + Estimation Change + TS that the user logged on issues before being unassigned from them during the sprint | ||
Not Completed | The sum of RT (end) of all not completed issues assigned to the user in the sprint after the end date | ||
| In Progress | Completed: Toggle off | Completed: Toggle on |
Completed (Initial) | The sum of TS of all issues assigned to the user and added to the sprint before the start date | The sum of TS + RT (end) of all issues assigned to the user and added to the sprint before the start date | The sum of TS of all issues assigned to the user and added to the sprint before the start date |
Completed | The sum of TS of all issues assigned to the user in the sprint after the end date | The sum of TS + RT (end) of all issues assigned to the user in the sprint after the end date | The sum of TS of all issues assigned to the user in the sprint after the end date
|