Observations on Scrum, Timesheets and Estimation

As a professional services provider, Readify is well practiced in the process of filling in timesheets to support billing functions within the business. Consulting tends to be a T&M style engagement so turning those time entries into money isn’t a major problem (although you wouldn’t have AR/AP staff if it was a complete no-brainer :P).

Moving into the project delivery space like Readify is puts a slightly different spin on timesheets. We effectively engage on T&M projects but because we utilise Scrum (or Scrum-butt variant depending on the client) we run into an interesting situation when comparing time estimates against sprint backlog items and timesheet actuals.

Going through the sprint planning exercise recently we sit our ideal day at about five productive hours of development per day, meaning that there was about three hours of other stuff not accounted for (not necessarily unproductive, but potentially unforeseen).

The problem is, when you have a team of four people that means that you might end up with 60 hours of “other stuff” and the client rightfully questions why they are paying for this.

It’s About Business Value

As we talked through the issue I pointed out that we really need to compare the submitted timesheets against the business value delivered, not the submitted timesheets against the estimates. Submitted timesheets include the 3 hours of “other stuff” which is difficult to track in a software project.

At the end of the day, dividing submitted hours by the estimated hours in a sprint backlog really just gives you a number and completely ignores the business value delivered. I think that this is probably the biggest argument for using a non-numerical sizing mechanism like T-Shirt sizing (S, M, L, XL) rock-paper-scissors style over planning poker.

I’d much rather have a conversation about value delivered to determine in the first instance whether there was some, and secondly how to optimise it sprint on sprint. I think when you get back to this you start being able to focus on what is really important. If you didn’t get much value out of this sprint then maybe the product owner didn’t prioritise correctly.

Whilst it is a bit of an overhead the team started tracking time in a timesheet to do some task analysis. Hopefully after a few sprints we’ll be able to talk intelligently about what some of this “other stuff” is and suggest ways to optimise it.

3 thoughts on “Observations on Scrum, Timesheets and Estimation

  1. Darren Neimke

    Having to account for every last minute is really just ‘bean counter’ accounting/project management.

    I’m perfectly happy when you say that you expect to average 5 productive development hours per day and to just leave it at that. — although I think that if you average close to 4 hours per day, per person over an extended period then you are not doing too badly.

    Trying to drill down and measure everything else beyond that is an exercise in micro accounting and should only be done if you have both the time and the inclination.

    The angle that you are coming from – which is to ask: “did we add value” – is the correct question to be focussing on imho. And the best way to determine that is, as you have also pointed out, from looking at your SCRUM objectives.

  2. silky

    I think you’re wrong (this will not surprise you).

    Either the “other stuff” is thinking and planning, and hence timesheetable, or it’s research (blogs, stackoverflow, other such things), and hence provides longterm value to the developer and your company, but not neccessarily (not metrically) the company you’re working at.

    With these hours, (research) you just need to explain for what they are: critical to the development of smart programmers and hence smart solutions.

    With the other hours (single developer thought-planning) then it’s also easy to explain.

  3. whibr01

    What may also be effective is removing the “other” as an item to capture time against, and identify what the “other” is – there may be more than 1 person using this same “other” category, and will help analyse where the effort is being spent.
    (Just been through this ourselves – I wrote a Silverlight front end to track [I wanted to learn Silverlight, so this provided good motivation to build something “out of hours”], and developers dont moan about capturing timesheets, because the Silverlight UI makes it “pleasureable” to use and had quick lookups to the projects / tasks / codes etc on our Unix product management system (so existing reports etc still work). But definately worth the time and effort to do properly, and developers also have buy in, because it helps them when we need to deliver an estimate on a task, because we can always say to sales and product team it took x hours the last 2 tasks like this – vs trying to make a point against a “thumb suck” have it done by date. Good times 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s