I like writing code.  I don’t really like administrative overheads and updating systems like Jira (or Rally or VersionOne or…).  But I know they are important and necessary.  Given that, I like to get the most out of them I can.

Management needs systems like Jira on Agile Scrum projects to track progress and roll up summaries so they can “steer the ship” (and make course corrections when necessary).  Having systems like Jira to record information in reduces the overheads of collecting that data.  And frankly, once you get into the swing of things its not really a lot of overhead in the grand scheme of things.

But how many fields should you have?  How much data to collect?  Is that one extra field really worth collecting?  These are important questions.  I have written before about the importance of measurement with respect to driving improvement.  One more field may not feel like much, but it does add up.  If the data is not used to a good reason, then its probably better to not collect it and let people get on with “real” work.

One piece of data I like collecting is logged hours (the actual time spent on tasks).  I also like collecting estimations of work before they start.  These fields can be useful to management (but not as much as you may first think), but boy can they be useful to the development teams.  Agile I truly believe is good for both developers and their customers (the Product Owners etc).  But there is a lot of trust involved.  The Product Owners have to let go of a far off deadline with guaranteed deliverables – this is hard to do.  They have to trust the development team that they will work as hard as they can to get towards the goal.  Instead, the Product Owners get tighter control over the reigns with better, more immediate, feedback loops.  Each sprint they can see progress (or lack thereof).  They can see real progress towards the end goal.  With this visibility, they have more immediate ability to change course if required.  And from experience, one of the hardest things for developers to do is correctly estimate how long a piece of work will take to complete.  And this is where logging hours comes in.

Getting developers to estimate work for tasks in hours, then logging the actual time spent, gives concrete feedback on how good the estimates were.  This may be a great thing for a team to review in their sprint retrospectives.  I really like poker planning (which I have also written about before), where the whole team gets together to do estimation.  Poker planning is a great way for teams to learn together about estimation, sharing the responsibility and burden of the estimates amongst the whole team.  The whole team commits to deliver a sprint after all.  The whole team also comes together to learn from the previous sprint in the retrospective meeting.

On projects that I have been on, different teams tracked information such as task effort estimates and logging work to different levels of accuracy.  In such cases I encourage teams to think about taking this on sooner rather than later.  Effort estimation and (reasonably) accurate logging of time spent I would recommend for the benefit of teams. As I mentioned above, I don’t think estimates are that useful for upper management.  Ultimately the rate stories get knocked off is good enough visibility at that level.  Logging hours is a tool really for developers – where to get the most out of it you need to be reasonably accurate in what you collect.

Going back to the idea “you can’t improve what you can’t measure“, I personally strongly recommend sprint teams have a go at estimating tasks at the start of a sprint and putting them in Jira, and then reasonably accurately logging the time really spent.  But even more importantly, then reviewing this to learn from old estimates to improve future estimates.  Developing reliable estimates then helps improve the trust between the development team and the customers of what is being built.  And that ends up with everyone being happier!