One of the more polarizing topics I have seen within the coaching community is on the subject of estimating tasks. Here are my thoughts on when I feel the practice is worth the risk.
Tracking Time Estimates
Because I staunchly reject the notion that there is a relationship between story points and time, it can seem contradictory for me to tell you to estimate your stories in points, and tasks in hours. Tracking task time, as with any metric would have to be done for a good reason. Most metrics can help in a specific instance, but any metrics can be counter-productive if used incorrectly.
So, is there a point at which I think tracking task estimates is useful? Yes, at the very beginning of an organization new to agile, and during the time when scrum teams are first learning how to be cross-functional. In those days, we focus a lot on the Definition of Done (DoD). Tasking provides a great way of illustrating the connection between DoD and the actual work we do. Often a team will struggle with estimating stories because they don’t think about the work done by the other roles on their team. An obvious example of this is when only developer work is considered when estimating -ignoring testing, documentation, rework, etc. Tasking helps raise awareness of the rest work in the DoD and tracking hours on those tasks is an effective way to demonstrate the impact of all roles on a team.
Tracking Actuals
Unfortunately, if you do step onto that slippery slope of time tracking in Jira, you’ll find yourself on the fast-track to capturing actual time as well.
I don’t encourage capturing “actuals” with the intention of filling out a timesheet. However, I can see some value in capturing an actual when it deviates dramatically from the estimate. Why? Because that gives us a point to discuss in the retrospective (i.e. Why was that estimate so far off? Was it chance, or was it something we should have foreseen? How can we get better in the future?).
As the teams get more mature, and they get a better handle on story points, then individual task estimates can go away, and when they really get a handle on DoD, then individual tasking can even go by the wayside. Like I implied above — right tool for the right job, at the right time. It’s not a universal and not a permanent practice.
Then there was that time…
There was one time, where I was very glad my team was doing that. We had a situation where the team was doing both new development and production support of their older product line. They were new overall to using Scrum instead of their waterfall SDLC, and in particular, their leadership was not yet accustomed to talking about the work they produced from an iterative perspective.
Over a series of sprints, it appeared that velocity on the team was declining, and had just dropped precipitously. During those sprints, I had called out that production support issues were becoming more frequent, and during that particular sprint, over 800 hours were expended on production support issues alone (a 10x increase over the norm). I couldn’t have done that without the team capturing the actuals on the bug fixes for the old product, and it went a long way toward helping leadership understand why a single metric alone doesn’t give the entire picture.
