I was wrong about tracking actual hours in agile

I once made a statement about closing out project management tickets that went something like “The actual hours a story / task took are the only metrics that matter”. At the time, we had a ton hoops to jump through to close a story out due to our tooling choices. We ignored most of them, but the actual hours field was something I told the team I valued. My thinking at the time was this would definitively show us if we’re coming up with accurate estimates and if we missed our estimates, where did we spend that time. This would give us solid data points to use across sprints and act as a spring board for future planning sessions. In reality it ends up being fruitless and does little to build a better team.

I generally follow Scrum when doing agile with teams, but I’m not prescriptive about it in any way. “Whatever works for the team” is another sound byte you’ll routinely hear me say and along those lines is where I had my epiphany. Just like the agile process itself is about enabling the team, estimation and time is all about the sprint. “How many stories can get done this sprint” is the real question around how long something will take. That’s it. It’s a scheduling exercise to maximize effective use of planned time. It’s just an estimate! Where that time went during the story / task completion is immaterial. Sure, it makes for a good conversation during the retrospective and leads to a fancy spreadsheet some dude in khakis can email around, but tracking actual hours in agile does little improve the estimation process of the team and certainly doesn’t increase the teams productivity. If neither of those things are happening as a result of tracking actuals, then I submit it is a pointless venture.


Be the first to leave a comment. Don’t be shy.

Join the Discussion

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>