If I Had a Tractor – Part 4

Agile Estimation and Planning

Part 4 – Velocity

When we talk of delivering value to our customers, we need to be very careful that we only count things that we’ve actually completed. The Definition of Done says I must mow, trim, edge and clean to meet my customer’s expectations. If I fail to deliver on any single aspect of that definition, the customer could reject my work, and refuse to pay me.

Think about that.  Even if I spent every minute of my weekend pushing the lawnmower around, and managed to cut the grass on twenty lawns — if I never touched the trimmer or broom, then despite the fact that I was BUSY the whole time, I didn’t actually COMPLETE any of the work.  What do I do now?  What do my customers do?  Do I just come back next weekend and do the trimming, edging and sweeping then?  Nice theory, but the grass will all have grown back by then!  So now even if I spend all weekend finishing the unfinished task from the previous weekend, the customer will look out their window and still see incomplete work. They would be well within their rights to withhold payment again.

This is why the Agile world is OUTCOME DRIVEN. It doesn’t matter that we are keeping our people active and working (busy) if they aren’t finishing everything in the Definition of Done – and hence delivering value.  

When you get right down to it, time estimates are not helpful at all. We don’t deliver TIME.  Our customers don’t consume hours.  They really don’t care how busy we were.  They care about results.  So we need a measurement of our ability to deliver completed VALUE.  In Agile, we call this Velocity.

Velocity is a measurement of the number of points of value that a team is able to complete in an iteration.  Only work that meets the Definition of Done is counted toward Velocity.  Partially completed work may as well not exist.

Velocity is a very useful metric, but it is not a universal constant.  It is a value that is unique to every team, based on their skills, tools, team structure, etc.

No matter what, Ed’s team is going to have a higher velocity than me.  First, their equipment is better -I can’t compete with that monster mower. And second, his cross-functional team can do tasks simultaneously.  In terms of clock time, from the moment they pull the equipment off the trailer until the time they roll it back up, something like 15 minutes goes by… (this includes Ed coming to the door for his payment).

Despite the fact that I’m telling you not to estimate in time, the concept of time keeps working its way into the conversation.  For instance, if I say Ed’s team takes 15 minutes from wheels down, to wheels back up on the trailer.  That’s time, isn’t it?  You’re right, I did talk about duration of the job.  But I didn’t ESTIMATE in time.  Do you understand why?

The reason we want to stay away from time estimation is because time estimation is not portable!  It cannot translate from one team to another. When Ed takes 15 minutes and I take 105 minutes, this causes a problem when it comes to translating our work.

My hours are not your hours.  The way I work and the experiences I’ve had will ultimately affect the amount of time it takes for me to deliver.  What if Jeremy, the kid across the street grabs his dad’s lawnmower and decides to get into this lawn-cutting game for some extra pocket money?  As it turns out, Jeremy’s mower is exactly the same as mine because his father and I both bought them when the local big-box store had a killer overstock sale.  Jeremy and I have the same equipment at our disposal.  Does that mean he is going to take the same amount of time that I will to mow my lawn?  I will bet you the answer is NO.  Jeremy and I have different levels of strength, speed, attention span, and even experience. I can virtually guarantee that we will perform the same amount of work in a different amount of time.

Furthermore, if Jeremy or I walk up to a house on the next block, intent on giving our estimate, and instead are informed that Ed was already there, and told them it’s a 15-minute job.  Does that mean Jeremy and I are now required to accept that estimate? 

How many times in your professional career have you found yourself being held to an estimate made by someone else?  It happens all the time. It’s even more disturbing when that estimate is made by someone who doesn’t even do that kind of work – or someone who doesn’t do it anymore.

Author: Michael Marchi

Michael Marchi CSM, CSPO, CSP-SM, CSP-PO, RSASP, AHF Management Consultant / Agile Coach & Trainer @ 42 North Unlimited (https://42north.llc) Co-Founder and Board Member @ APLN Chicago (https://aplnchicago.org) Co-Host [here's this agile thing] podcast (https://htat.show)