Estimates vs. Actuals

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.

Agile Estimation Primer – Part 2

Our step-by-step guide to applying the concept of relative sizing to estimation continues. In this section we’ll build backlogs at various levels of detail – from high level product road maps, through release planning, and onward with increasing levels of precision all the way down to detailed iteration planning…

If you haven’t read Part 1 yet, please go back and make sure you understand the relative sizing concepts introduced there.

Continue reading “Agile Estimation Primer – Part 2”

Agile Estimation Primer – Part 1

A step-by-step guide to understanding how to apply the concept of relative sizing to estimation, and then using that understanding to build backlogs at various levels of detail – from high level product road maps, through release planning, and onward with increasing levels of precision all the way down to detailed iteration planning…

Continue reading “Agile Estimation Primer – Part 1”

Tens, Romans & Lettermen – Part 2

Far be it from me to leave well enough alone. Let’s amp this discussion up to the next level. **

Part 2 – Advancing the Discussion

In Part 1 of this topic, we demonstrated why multi-tasking is bad for productivity. Some of you will be just fine with that conclusion. You probably are perfectly comfortable waiting for all three columns of the grid to be generated in sequence, and then just accepting the end result.

But what if there was a reason not to be so comfortable with that result? If that were the case, this discussion could get pretty interesting.

Note: If you haven’t read Part 1 yet, you should go back and do that first.

Continue reading “Tens, Romans & Lettermen – Part 2”

Tens, Romans & Lettermen – Part 1

A simple game to illustrate the cost of task-switching *

The title of this post is a terrible play on words. Every time I think about it, I’m reminded of the opening lines of Mark Antony’s funeral oration. It’s cool if you don’t agree with the title. Lend me your ears anyway…

Multi-tasking via Task-Switching is a costly practice. This game can be used to illustrate this point with things you can probably find readily available in your desk or office-supply closet. The material is presented in 2 parts. Part 1 reveals the exercise in its most basic form. Part 2 expands on the original premise to learn even more…

Continue reading “Tens, Romans & Lettermen – Part 1”

If I Had a Tractor – Introduction

Here the metaphor of lawn care serves as a gateway into a discussion of defining and estimating work in a manner similar to what new agile teams are first called upon to learn. We then build on those concepts to demonstrate the rationale for maintaining cross-functional teams. And finally how to budget for these activities.

Continue reading “If I Had a Tractor – Introduction”