Agile Time & Performance Tracking

Time Tracking – Real or Ideal hours?

The concept of “Ideal Hours” in Agile begs the question of how it relates to real schedule hours or timesheet tracking. This is actually a misnomer, because Ideal hours estimates are estimates of “real time”, just only that amount of time actually spent on that task. To be helpful, consider the following scenario:

Two Developers are asked to estimate how long it will take them to code 2 new methods in the application:

Developer A: I’ll get this task done in 1 day (8 hours)

Developer B: I’ll get this task done in 6 ideal hours

Both Developers begin work at 9:00am the next day.

At 9:30am, both stop to attend their Daily standup meeting, which lasts 15 minutes
At noon, both stop to have lunch, which lasts one hour
At 2:30, both stop because then need to research a new security parameter that now must be included in methods like this. Their research takes 30 minutes
At 5:45, each stops coding and performs a peer review of the other’s work, which takes 15 minutes.

Both Developers finish checking in their code at 6:00pm that day.

So, which Developer was correct in their estimate?

The answer is that they both were correct. The difference is, the 6 ideal hour estimate from Developer B was made knowing that there are other things that have to happen that day which are not part of the actual coding, so he did not include those in the estimate. All in all, he did actually spend 6 hours just on the coding of the method.

In Agile, in order to make estimation consistent for the entire team, we ALWAYS estimate using ideal hours. We then only plan for a certain percentage of the team’s scheduled hours to actually BE ideal hours to allow the kinds of activities listed above to be pre-planned when planning a Sprint (see Sprint Capacity guidelines below). Thus, a team’s scheduled hours will always be fully accounted in a Sprint.

Measuring Performance – Individual or Team?

The Agile framework is a team-centered model: there is no hierarchy among team members, all participate equally in their respective roles. In this kind of environment, how should performance be measured? In short, it should be assessed each iteration at both the Team and Individual level in the context of the Sprint Retrospective

Team Performance

Team performance should be measured primarily by its velocity. These questions should be asked by the team to itself every iteration.

Are they delivering consistently?
Is their velocity increasing due to continuous improvement action items?
Etc.

Individual Performance

Individual performance can be characterized as described below. The kinds of questions listed should be asked by the team members of themselves during each Retrospective, and corrective action should be identified and planned within the Retrospective framework.

Product Owner Performance

Product Owners’ performance should be based on their ability to keep an organized, prioritized, clearly expressed Solution backlog:

Are there always enough Ready stories for the team to plan the next sprint?
Are the Acceptance Criteria clear and easy to understand by the team?
Is scope frequently added during Sprints? Or is it properly added to the backlog?
Etc.

Scrum Master Performance

Scrum Masters’ performance should be based on their ability to maximize and increase a team’s velocity potential:

Are they helping the team resolve their impediments?
Are they enforcing the Agile ceremonies?
Is the team’s velocity increasing?
Etc.

Team Member Performance

Team Members’ performance should be based on their ability to estimate and deliver tasks within a Sprint:

Are estimates fairly accurate?
Are they able to deliver the work they commit to?
Are they staying on task and only doing the work that is slotted in the Sprint?
Are they proactively identifying ways that the tasks can be done faster?
Etc.