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.