Tracking Hours Spent: Appropriate and Inappropriate Usage

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 (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 Review Meeting, 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.

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
13 comments on “Tracking Hours Spent: Appropriate and Inappropriate Usage
  1. Anonymous says:

    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!

  2. Michael James says:

    http://groups.yahoo.com/group/scrumdevelopment/message/22046

    From the ScrumDevelopment Yahoo Group:

    Hi,

    Just wanted to share some positive effects I observed when we started
    using burn down charts instead of typical metrices (effort variance
    and schedule variance).
    When we were using effort variance and schedule variance metrices,
    developers were reluctant to open up and speak. We were always finding
    some reasons for why original estimates were not met. These metrices
    did not give clear idea about where we stand.
    With burn down charts we now get very clear visibility into where
    the overall development stands. People openly discuss about newly
    identified tasks. Our organization is not using Scrum. I am just
    trying out things in my group.
    I am curious to know how did Ken Schwaber and Jeff sutherland
    invent burn down chart.

    Thanks,
    Unmesh

    –mj
    Michael James
    Software Process Mentor
    http://www.danube.com

  3. Mark Bearden says:

    Michael, I enjoyed your blog post, but I have
    a question in response to your comment:

    …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.

    I have heard such a claims before, but I
    can’t recall them ever providing any evidence
    or justification for this “pessimism” about
    trying to track and utilize actuals.

    Could you provide any references to research or
    anecdotes on this topic, either from
    personal experience or otherwise?

    My own take is that I’m agnostic on this. I
    don’t expect that counting “actuals” and comparing
    to original estimates *must* help, but my
    own anecdotal experience makes me think that
    in some cases, and if done “right”, there can
    be benefit. I also don’t see clearly
    the pitfalls that can’t be avoid, again, if
    things are “done right”. By “done right”, I
    mean at a minimum that…
    – use of actual vs. estimate comparison is
    reported at team/project level, not at
    individual developer level
    – stated reason for checking actual/estimate
    comparison is to allow the *team* to
    improve accuracy of new estimates over time
    – “underestimating” is not presented as a
    “bad” thing or failure (while this may be
    hard, I believe I’ve pulled it off on a past
    project)

    I have seen one project team actually *seem* to
    get better at estimating after tracking
    actual vs. original estimate for a few
    iterations. One reason may be that we
    discovered that certain *typesI of tasks,or
    tasks involving certain technologies, tended to
    be the ones we underestimated most
    consistently as a team. After becoming
    more self-aware of this, we did over time
    appear to become more accurate as a team
    with our estimates.

    So to repeat my question, can you provide
    any research or anecdotes to back up the
    wide-spread pessimism that you share about
    the value of tracking the “actuals”? I would
    personally be interested in being involved in
    research on this topic, if you know of anyone
    who hasn’t already dismissed the question as
    a closed case.

    Thanks.

    M. Bearden
    Atlanta, Georgia

  4. Michael James says:

    With enough effort I’m sure it’s possible to make task-level estimates more closely resemble actuals for similar types of work. I’ve never seen anyone get that good at it, but I’m sure someone out there is good at it, or good at appearing to be good at it.

    It’s a moot point because in Agile we use a more useful (and self-correcting) measurement to inform our release planning: Velocity.

    Velocity (in Agile/Scrum) is how much potentially-shippable product actually got built each Sprint. Measuring actual velocity in relative story points completed per Sprint (“yesterday’s weather”) automatically corrects for any tendency to overestimate or underestimate.

    Focusing down at the task level (micromeasurement) is an attempt to measure individual performance, while in Scrum we’re more interested in team performance on whole units of product (Product Backlog Items) that are potentially shippable (coded/tested/validated). This tells us much more about when we can expect to ship a given set of features, or how many features we can expect to ship in a given amount of time.

    More about this here:
    MacroMeasurement.pdf

    Also see Mike Cohn’s book _Agile Estimating and Planning_.

    Michael James
    Software Process Mentor
    http://www.danube.com

  5. Jarno Vähäniitty says:

    Unfortunately, the link to
    http://danube.com/system/files/MacroMeasurement.pdf
    does not seem to work. I would be very interested to see what it says!

    Specifically, I’m looking for info to back up the “…seemed like a good idea in the 90s’ but did not work in practice” statement, which seems intuitively true to me (though I can’t explain it currently)”

  6. Nickw says:

    Hey Jarno,

    You’ll need to be logged into the website to access that file 🙂

    Nick Whalen
    Danube Technologies, Support Specialist

  7. jvahanii says:

    I initially thought so as well, but even after logging in (userid jvahanii, just tried it again), I still get the “You are not authorized to access this page.” message.

    Can you help me? (jvahanii a t g m a i l dot com)

  8. jvahanii says:

    Now I got the PDF, thanks!!

  9. jvahanii says:

    > “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.

    I’ve now read the PDF. I’m still looking for good evidence and/or argumentation for the above statement. If anyone can point such material to me, great!

  10. Michael James says:

    I’m not sure how many projects would have to go behind schedule, or fail outright, before you’d have enough evidence….

    Fortunately it’s a moot point because in Scrum we can measure velocity empirically.

    –mj

  11. Nickw says:

    A note to all who used to encounter this, we have disabled this requirement to access files on our website. You are still required to be logged in to download ScrumWorks, however all other files are available without an account.

    Enjoy :).

    Nick Whalen
    Danube Technologies, Support Specialist

  12. Michael Motngomery says:

    How should hours for tasks involving multiple team members (i.e. design meetings or swarms) be maintained?

    Should it be by task length only or by task length * # of team members?

  13. Victor Szalvay says:

    If you’re tracking estimated spent on tasks (in a tool like ScrumWorks) the recommended course is to take the time spent and multiply times the number of people involved.

    So if you have a task which took 3 hours to finish for a group of 4, then the total time spent should be 12.

    Hope this helps.

    Victor Szalvay

Leave a Reply

Your email address will not be published. Required fields are marked *

*