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.

Agile Estimation and Planning

Introduction

With the advent of agile methods and their affinity for rapid delivery cycles, traditional estimation models are coming up wanting.  Agile estimation, while undoubtedly faster is also difficult for some to grasp.  Expressing work in terms of time has been burned into the software community’s psyche.  But it doesn’t have to be that way.  I coach agile teams in making the switch from traditional development models to agile.  In doing that, I help them learn new ways of estimating.  This series of articles will hopefully explain – through metaphor, why the old way of estimation was problematic, and how the new way addresses those shortcomings, is faster, is no less accurate, and can even be fun!

If I were to stand up in front of a room full of people, and select individuals at random to answer this question:  “How big is your lawn?”, I would get a variety of responses.  Many common answers are “1/4 acre, 1/2 acre, 10000 square feet, or maybe 900 square yards”.  The answer I would not expect to get is “45 minutes”.

Why is that?  For one thing, I asked for a size estimate, not a time estimate.  Yet, all over the globe, if I ask a software developer or project manager to estimate the size of a feature, they will generally answer in a number of hours, days, weeks, months, etc.

Time instead of Size.

This behavior has been ingrained in the development community for decades.  Agile methods have attempted to break that habit by requesting effort estimates as a measurement of relative size (often story points).

Indeed, I have been coaching and guiding teams long enough to have seen a variety of attempts to shift teams to “how big?” rather than “how long?”. Admittedly, it’s a really tough transition to make. And a very common way of approaching that transition is to offer a crutch – usually a conversion factor … you know, so the team members can wrap their heads around the concept more easily.  A common one I’ve seen is 1 Story Point = 1 Ideal Day.  SAFe offers the crutch that 1 Story Point is about 8 hours.  I’ve seen someone recently amend that to a range from 1 to 10 hours.

I’ve adopted a lot of truisms in my years of observation and continuous improvement. One that has stuck with me consistently though my agile career, is simply this:  “There is no direct relationship between Story Points and Time.”  If I want to leave some wiggle room, I might say “no reliable relationship” or “no consistent link”.  Of course then I’ll toss in that story points and time is not constant from team to team.  Any attempt to build that bridge will be fraught with drama, and lead to disappointment.

But nobody believes that.

And so, again and again, those who won’t acknowledge the past, repeat it over and over.

I’m hoping this series of articles on Agile Estimation and Planning will serve to save even a handful of you from following so many others in walking off that cliff.  If nothing else, it’s a chance for me to hone my explanation.

Feedback is welcome, please weigh in.

• If I Had a Tractor – Part 1
• If I Had a Tractor – Part 2
• If I Had a Tractor – Part 3
• If I Had a Tractor – Part 4
• If I Had a Tractor – Part 5
• If I Had a Tractor – Part 6
• If I Had a Tractor – Part 7

Slide Deck to support this material: