I was listening to a conversation just a short while ago.

Somebody fairly new to Agile was talking about how they were getting their team to log the hours that they were spending on stories in Jira and also using Jira to re-estimate or burn down on a daily basis to track progression within a sprint and to be honest they got shouted down for basically being young an naive.

I’m neither of these things and sometimes I do it too and I do it because it makes sense to do it in a particular situation and guess what, in my experience it can and does work.

I wrote a little while ago that sometimes, dependant on context its OK not to use story points, that Story Points Suck .. sometimes.

That when you are struggling to just get the basics working right, that fighting with the PM & PMO about using story points is a battle for another day, perhaps not too distant but not right now, so just estimate in hours initially,

For me at times we have to be pragmatic, we need to show some progress, so get it in, get it working, make it better.

The other side of the PMO coin is the question,

How much time did you spend working on those things that you estimated?

I’ve worked in plenty of places where bean counting is prevalent and where this can be used as a large stick to beat people with, we know the kinds of questions asked.

“You said it would take x and it took y, why?”

However I see logging the hours we worked and burning down as being something that can be used to not only protect the team but also to drive out difficult questions as it gives us real world metrics that can start the right conversations.

Remember the Deming quote:

“Without data you just another person with an opinion”

This needs to be done with education about why estimating in the complex environments is not overly bright or useful, I use Cynefin and a short talk to do this.

But lets be honest the whole #noestimates movement is ultimately predicated on good flow and small consistent batch sizes, so we can move away from story points to count of stories for predictability, in other words its a measure of maturity.

Great article here by Chris Matts, All Estimates are Waste, some are useful.

Once have logged time it can show us a number of things

Sustainability: If we have people logging lots of hours, more that they should then we may have a problem with sustainability, people will burn out, it will show us if we have high utalisation so we can have conversations about this, remember Little’s law.

Transparency: Whether we are “one item at a time” or “time boxing“, things can and do come left of field at the teams and we cannot always just bat them away, for example urgent live fixes (chaos), logging hours against stories allows us to tell the story of how much we have been context switched.

I had a team who were being constantly dragged off to fix the environments on which they were working, so sprint forecasts were being missed. This work was invisible so by ensuring that we had stories for the work and that time was being logged we were able to show how much pain having poor environments were causing and more to the point how much money it was costing, not just in developer time spent but also in the lost opportunities that they were not spending their time on.

This prompted some strong words at program level about getting the environments fixed.

Flow: If we are burning down hours and re-estimating everyday then we can show quickly if we are likely to miss a commitment or forecast, letting stakeholders know early and avoiding those “failure to deliver” conversations.

I know I get incredulity here around the “reponding well” but in my experience people hate surprises and respond well to being given warning and treated respectfully not just told at the end of a sprint that the goal was missed.

It can also allows us to avoid the “5-to-5” problem, whereby people doing the testing get things at the last minute in a sprint, this can also be avoid by focusing on finishing the highest value items in a sprint first and finish items one at a time.

Calibration & Estimation: If you have some actual hours logged against stories then this can be used to feed back into the estimating process, so the next time you do something similar you have empirical evidence of how much time it actual took and who knows because of this you improve your predictability.

As Agile coaches, we all go around with a big bag of Agile tools and techniques, so please don’t just dismiss estimating in and logging hours, they can have utility and value when done in the right place at the right time, like most things.