In which we abandon time sheets and nobody dies

We are an agile team. We build data science products for our clients.

Sooner or later it's nice if we can bill those clients for progress on their jobs. It's even better if we can pat ourselves on the back and head off to the pub at end of sprint, knowing we have delivered that work efficiently.

...and that's where time-sheets come in, right? So easy, so accountable. Everyone's week, allocated out, tracked. None of that precious contractual obligation going to waste.  

Except it's not really like that, is it? What about that half a day lost in pair programming through a really weird bug? Or that bit of extra development time we spent to make the visuals extra special?  Are those projects off track because they took longer?

Plus, there is not a human being in existence that looks forward to time-sheets.

.... It's miserable,

.......... So we threw them out. 

.................. Just like that. 

That was a year ago now and it was a little weird at first but (other than the odd bit of hourly consulting) we haven't looked back.

How do we tell clients what we have done?

There are two key things we do differently to a lot of traditional professional service firms:

• Our contracts/assignments are costed and billed using milestones based on deliverables, not time. 
• We estimate effort in points, from proposal stage, right through. 

We don't do a lot of 'time and costs' work any more so this was not a big change for use.  For the majority of our projects we develop a set of deliverables and we estimate effort using sprint 'points'.  For us, one point is roughly equivalent to one analyst/developer for one day (but it doesn't have to be). 

Sometimes we still adjust the costs per point based on an estimate of the person/skill required.  This is a good compromise for clients with traditional procurement forms with time and costs tables.  We have been moving towards a simpler point-based complexity estimate and one (or two) basic team rates.  This was a little weird at first but so much simpler. 

We also report progress (and bill) against these deliverables.  Whether a task takes the length of time we thought, or longer the value is in the thing we deliver. 

What if you get it wrong?

It's simple.  Value is linked to deliverable. 

The cost is the cost unless the deliverable changes or something happens (external to us) that causes us to re-evaluate the complexity.  For example, if it turns out we need to add in a deliverable to access and clean additional datasets because we (and the client) have adjusted the deliverable requirements, we would have a conversation about that.  If we decide to add in some extra development work, or it just takes longer than we thought, that's for us to deal with.

How do we know we are earning enough to keep ourselves fed?

This is where the agile approach deviates from standard professional service firms.  We don't use cost per hour or utilisation for individuals. 

• You need to know how much a "point" is worth (or needs to be worth, to make this whole thing fly).  We have been slowly developing a set of KPIs that help us track this but it's still developing and simplifying as we learn.
• You need seamless tracking of points delivered, value delivered throughout proposal, development and delivery.  There are tools that help with part of this but it's been a little frustrating.  If you have suggestions of a simple end-to-end solution that integrates with slack and trello - let us know. In the meantime, we are building our own solution (stay tuned for that...)