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.

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”

Accentuate the Negative?

The instant message app chimed on my desktop. “How confident are you that we won’t find any more defects in testing?”, the department head asked. I glanced over at the task board, at the lone sticky note sitting in the “In Progress” section: “Architecture Review”, it read. I popped open the chat window, and responded, “100% sure. We are done with testing.” I watched the window for a moment as the message app informed me they were typing their reply. “Okay. Because I’m about to go report that to the senior managers.” “No problem,” I typed back. “See you at the demo, tomorrow.” Continue reading “Accentuate the Negative?”

Give a Boy a Hammer…

“If you give a boy a hammer, he will suddenly find that everything looks like a nail.”

In some ways, this is how Agile is being applied in the industry today. It doesn’t matter what problem you need to solve, hit that nail with a Hammer. You want to get better predictability? Hammer. Quicker time to market? Hammer. You want to improve employee morale? Hammer. Continue reading “Give a Boy a Hammer…”

Agile vs. Waterfall – Improved Performance is NOT Guaranteed

I am frequently asked to give a brief overview of Scrum to people who are unfamiliar with Agile concepts. In the course of giving those lessons, I almost always see a look of shock at the almost cavalier way that we agilists claim that Agile methods will give a better result than traditional methods. I like the look of shock. It shows that they’re paying attention. Continue reading “Agile vs. Waterfall – Improved Performance is NOT Guaranteed”

On Tweaking Estimates

As Product Owner for the project, I get to field a lot of interesting questions. I woke up this morning to the following question from one of my teams:

Hello Mike,

In our current sprint, we have planned 8.5 user story points. But after task breakdown we can see for a couple of user stories, actual story points differ from the estimated story points. What is the correct course of action in this case? Do we need to update product backlog for revised user story points? Then we can say the team is working towards achieving 11.5 user story points! Also, since our [project gate commitment] is nearing, should we reexamine the estimates in the product backlog, and revise them for the remaining user stories?

Continue reading “On Tweaking Estimates”

Sailing Metaphor for Agile

When I was in high school, my friend Scott and I took his father’s sailboat out on the lake where our families spent summer vacation.  We had each been sailing numerous times; always as crew, never at the helm.  We both knew the lingo; “Come about” and “Pull that jib in tighter!”.  I had taken a boat safety course, so I knew all about life jackets and right-of-way.  There was even a page in the safety manual that talked about sailboats and gave a handy chart for the points of sail.  We were set for adventure! Continue reading “Sailing Metaphor for Agile”