The new release of ScrumWorks Pro has a feature allowing you to track how many hours your team spent on individual tasks.
In Scrum, we're mostly concerned with how many hours are *remaining* on each Sprint task. Agilists regard how many hours we already spent as water under the bridge.
Nevertheless, our customers have pointed out a few legitimate reasons a minority of organizations might want to track actual hours spent (misleadingly* called "actuals" by some).
- You realize detailed timesheets impede real progress, but you must provide them to bill your customer, or distinguish work done for different customers.
- You realize detailed timesheets impede real progress, but certain categories of tasks are treated differently for tax or regulatory reasons. For example, you're in Canada and get tax credit for doing R&D.
- You realize detailed timesheets impede real progress, but you want some temporary way to show upper management your team is getting buried by impediments (interruptions, lack of support, people getting pulled off to fix P0 bugs, etc.).
Of course this feature has the potential for abuse:
- The losing game of trying to make your task estimates match your actuals, or "learning to estimate better" at the task hour level. This seemed like a good idea in the 90s, but didn't work out in practice. Measuring how many backlog items the team gets done/done/done (coded/tested/verified) has proven more effective. Much more about micrometrics vs. macromeasurements here.
- Trying to identify slackers. This is the wrong tool for this job. Agile teams collaborate on tasks. Visibility occurs through the daily Scrum, the Sprint Retrospective meeting, etc. If you suspect people are slacking, how about talking to the team about this rather than trying to spy on them through the numbers? Abusing team self-management artifacts such as the Sprint Burndown Chart only makes them less useful for team self management.
--mj
Michael James
Software Process Mentor
http://danube.com/blog/michaeljames
* While the traditional limited meaning of "actuals" is time spent (in hours) divided by work completed, the Cohn chart (supported by both ScrumWorks Basic and Pro) measures actuals in terms of work completed (the "done" flag on a PBI) divided by time (the fixed Sprint duration). It's simply the reciprocal of the traditional actual measured in different units. But it's still an actual -- in fact even more actual because our units are more empirical. A completed backlog item with robust acceptance criteria is a better measure of product doneness than a completed task.
The distinction introduced by the new features is not "actuals" vs. "no actuals." It's actual *hours* spent for work done vs. actual work done for time spent in Sprints. All we've done is change the units and take the reciprocal.
| Attachment | Size |
|---|---|
| Tracking Hours Spent blog.pdf | 112.69 KB |
Making a person responsible for figuring hours spent on individual tasks, puts the burden of work load where it should be... on the employee.
Instead of asking the PM who has the tendency to estimate how much time he/she wants it to take.
Even for the employee, sometimes it's hard to know how much time a task will take until the employee spends a day working on it. That's why daily burn down is so effective.
In my opinion, learning to break down work into accurate estimates is an important learned skill.
Thanks!