If I Had a Tractor – Part 7

Agile Estimation and Planning

Part 7 – Stable Funding

So far, we’ve been able to see that relative sizing can help us eliminate ownership bias in estimation. We’ve shown how the concept of velocity can give us a means of projecting when a collection of jobs can be completed. We’ve shown that adjusting team size into groups with the ability to execute cross-functional tasks at the same time can lead to efficiency.

But we haven’t talked about how you budget for these situations. I am frequently approached by clients wanting to know conversion factors for story points and hours, so they can calculate cost of a feature by multiplying hours times resource cost — just as they always have. As we’ve seen in the previous sections, even in a conversation about something as simple as mowing a lawn, the connection from lawn points to hours is tenuous at best. And to quote myself from an earlier point in this section: “THERE IS NO (consistent) RELATIONSHIP BETWEEN POINTS AND HOURS!”

So what are we to do? It’s actually easier than you might think…

Let’s begin with my one-man lawn-mowing business. Recall when I was asked to estimate how many lawns I could do in a weekend, I gave the forecast of 16 lawns per weekend (where Definition of Done = Just Mowing) and 9 lawns per weekend (where Definition of Done = Mowing, Trimming, Cleanup). What REALLY IMPORTANT assumption am I making here?

When I made this forecast, I assumed that I would be the only one working on my team, and I further assumed that I would be devoting all of my energy to the work of my business. In project manager parlance, I am 100% allocated to my business… that is to say, this is the only thing competing for my attention.

In my imaginary iteration of one-weekend, I will devote two full working days of 8 hours each to the effort. I therefore have a cost to my business of :

Labor Cost = 16 hours (per weekend) x (my hourly rate)

For this example, let’s assume I’m going to pay myself $10 per hour. So my labor cost for my Team is $160 per weekend.

So if I make good on my forecast, a Velocity of 9 points, will cost

$160 / 9 points = $17.78 per point

Further, I use one tank of gas each time I mow my 1-point lawn, so I could reasonably extrapolate to say that a 2-point lawn would take 2 tanks, and a 3-point lawn would take 3 tanks. The gas tank on my mower holds 1/4 gallon (or 1 quart) of fuel:

Material Cost = (1/4 gallon per point) x ($4 per gallon) = $1 per point

Nine points of lawns will cost me $9 in fuel. So total cost for my business is $160 + $9 = $169 expense PER WEEKEND.

For my team, each lawn point is going to average out to:

(Labor) + (Material) = Total Cost

$17.78 + $1.00= $18.78 per point

Which means I need to charge $19 per lawn point … let’s call it an even $20 to make a profit on my business. My business nets $1.22 per job.

Why would I do this? I can hear the project managers and delivery managers screaming their heads off. They’ve actually been doing it since I calculated Labor Cost a few paragraphs back, and it’s starting to give me a headache. I know why they’re upset. I calculated the cost of my team members by potential time, not by time spent working. It’s like I’m paying a salary for hourly work! That’s crazy! Who would do that?

I’ll give you a minute as you gaze into the looking glass…

Yes, my friend. You are that crazy, wonderful person who pays a fixed salary to your people, regardless of how much work they do! And let me tell you, it’s the reason everyone gets so wrapped around the axle on budget. Good grief, listen to them: “Why am I paying for them when they’re not working? That’s not fair! I should only pay for the time they’re doing work! Well, I’ll show you! I’m going to pay someone to make sure everyone is busy every second of the day so I don’t waste any money on idle time ever again! Yeah, that’ll do it! And because I’m so good at getting project managers to get workers to work, someone should pay me too! Which means I need to be busy, every minute of the day… uh… micro-managing them into a frenzy of performance…”

Done? Welcome back. Easy to fall down the rabbit hole, isn’t it? We’re going to have to agree to make a few adjustments on how we look at our teams. Our teams are not made up of individuals contributing moments of time to a string of semi-related tasks. Semi-related tasks are the same as multi-tasks. They are inefficient. Refer back to the previous discussions.

For years, you’ve piled task after task on your folks in the name of keeping them busy, but in between those tasks, you wasted their time to task-switching. They weren’t actually efficient. You just chose to ignore the waste.

So for the time being, let’s assume that we will have a steady backlog of lawns that we need our team to mow — more lawns than they could possibly do in a single weekend. Let’s further assume that management of these teams will be limited to making sure they are assigned to work on the most important lawns first, and that they always try to finish every lawn they start so there is a steady stream of value being produced. Those last two suppositions are vital. To make sure they finish what they start, they can’t be assigned more work than they can do.

As long as the value being produced exceeds the cost of producing it, we’re going to make a profit, so for this moment, let’s agree that profit is good, and any profit is sufficient to justify continuing this thought exercise. Agreed? (Don’t worry, we’ll worry about maximizing profit in a future section.)

Until this moment I’ve talked about my one-man team. That’s good as an illustrative jumping off point, but I’m not the kind of team we should be worried about…

Now, let’s take a look at Ed’s Team. He has three guys, and let’s say they all earn $10 per hour as well. Ed’s labor expenditure is triple what mine is ($480 per weekend). Also, his monster machine uses more fuel than mine, plus he’s using a gas-powered lawn trimmer. So Let’s just say that Ed it burning $3 in fuel for every point of lawn his team mows.

When we asked Ed how many points he could deliver in a weekend, he laughed at our guesstimate of 60 points per week, and said he can really only do more like 36. So let’s use that… and pay close attention. The math is calculated the same.

$480 / 36 points = $13.33 per point

For Ed’s team, each lawn point is going to average out to:

(Labor) + (Material) = Total Cost

$13.33 + $3.00= $16.33 per point

Which means he could charge $20 per 1-point lawn as well, and still make a profit. (He actually charged me $25 – but remember, he has to truck the equipment around… which has far more to do with the reason for his velocity only being 36 points).

What do you think would happen to either of our forecasts if our teams weren’t fully allocated? Take for example, Ed’s leaf-blower guy, Joe. Of the three jobs, Joe has the easiest job because it takes less time than the mowing and the trimming, plus he can’t actually blow grass clippings that haven’t been deposited on the sidewalk yet. This means that at times, it may look like Joe is idle. To correct this, what if Joe was assigned to work on another lawn care team? I think you can see that sets up Joe to become a bottleneck to completing work. What if the two lawn care teams are not operating in close proximity, necessitating travel time (task switching cost) as he shifts from one team’s job site to the other?

This is the next assumption I want you to embrace. It is not uncommon to put people on multiple teams, and forget to account for the transit time between the two. We inevitably slow down both teams as they wait for the shared resource to appear… all in the name of keeping one resource busy. Instead, I’m sure there are a million tiny non-leaf-blowery things that Joe could do to make sure the job goes smoothly. Maybe he grabs a small mower and gets in between tight spaces the monster mower can’t reach. Maybe he helps out with some edging, or collects the money from the customer. Joe isn’t just a leaf-blower anymore! He’s a hero.

So if we take these assumptions and bundle them together, we arrive at an interesting premise. Every member of Ed’s Team should be fully allocated, and fully committed to completing each job they take on. Because of this, each member of Ed’s team will be as busy and engaged as possible, each focused on the delivery of value. And because of that we can now make a huge leap forward in our budget conversation!

Our fully-allocated, salaried team, with a steady backlog of work available to them, will COST us the same amount – every – single – weekend. So if Ed’s team comes to a point where they can reliably produce 36 points of lawns each weekend, and they always cost the same amount every weekend, then we are in a stable funding state, where the cost to customers are proportionately calculated by how much value they received.

Per our earlier calculation, Ed need only charge $16.33 per 1-point lawn, and double that for 2-point lawn, and triple that for a 3-point lawn, and 5-times that for a 5-point lawn, etc… Then Ed will make sure he rounds up so the business gets a cut of the profit.

In a Stable Funding model, it pays to keep our teams together and static so they can become predictable. When that association manager comes to Ed, and asks what it will cost for him to maintain all the lawns in a subdivision, Ed knows his cost per iteration, and he knows how many lawn points he can deliver for that cost.


If I Had a Tractor – Part 6

Agile Estimation and Planning

Part 6 – Multi-Tasking and WIP

How good are you at multi-tasking? Given the pace of information we are inundated with each day, you would think you’re very good at it. Think about something as simple as walking down the street while checking your phone, or reading a book while you watch television. How about driving a car while having an animated discussion with a person sitting beside you? All of these are examples often cited to prove that multitasking is possible.

Your brain would disagree with you. The human brain is only capable of active focus on one complex task at a time. It’s a bit like a computer. Each processor in the computer is only capable of doing one thing at a time. To give the illusion of allowing multitasking, the processor uses task-switching. The computer switches tasks very fast – many thousands of times per second. It pauses the execution of its current task, then saves the current state of the task into a buffer, then loads the context of another task from a buffer into active memory (reestablishing context), then it executes that task for a time. This process may be very fast, but it is not without cost. At the very least, there is a cost of clock cycles as the tasks are swapped – cycles lost while neither task can be monitored or advanced. That swapping time is wasted potential.

Some tasks are very dynamic, requiring constant attention and course-correction. Others are very mechanical and repetitious. Advancing a timer, running a fan, and illuminating a display are examples of tasks that don’t require higher processing. They can be relegated to autonomous, lower capability systems. Thus, even while the computer is calculating the precise time to pump the brakes in an emergency stop, the tire pressure monitor continues to check the pressure, and the fuel injection system continues to follow the last command it was sent.

Your brain is very similar. Higher order functions that demand complex thought will require dedicated attention. But even while your brain does this, you continue to breath, or continue to walk in a specific direction. This is especially true of familiar, repeated tasks. Many complex functions can be relegated to following a series of repeatable tasks. When you first learned to drive, it was exhausting. You were continually monitoring everything around you, including the act of applying pressure on the gas pedal and making micro-adjustments in steering. As you became a more skillful driver, it became possible to relegate some of those activities to automatic processing. Just because you open your mouth to talk to a passenger, doesn’t mean your foot will come off the gas pedal. But if your focus is too diverted to that passenger, you may not spot the obstacle appearing on the road in front of you. Often you will — the task switching is rapid, and the pattern matching process is fairly robust, so you may just catch the hint that something has suddenly changed and demands immediate attention. Your foot moves to the brake, your hands grip the wheel, and you brace yourself as you engage an emergency stop! Amazing, right? But you know what you didn’t do? You didn’t continue that conversation with the passenger. You couldn’t. The processor was busy averting catastrophe.

The same is true of the work we do every day. The hard work. The creative work. The things that need concentration. You are only capable of focusing on one thing at a time. Sure. You can multi-task. You can do a task-swap the same as the computer. But it takes time to do it. Time during which neither task is able to be actively addressed. The automated things keep going in the direction they were going, but the complicated stuff gets swapped out. You’ve probably heard that putting someone on two teams will cause a loss of 20% of their available time to task-switching. This is true at the story level It’s also true at the task level. 20% of your capability is lost every time you need to switch tasks.

So if I were working alone, and trying to save time while mowing lawns by mowing and trimming at the same time. Do you think that would work? Both actions require active attention as the situation is ever-changing. Imagine trying to do that! Walking your mower along the stone-lined flower beds while you aim the trimmer at the stones that form the edge of the bed. (BTW, I actually tried to find an illustration of someone doing this. I figured that some Einstein out there would have photographed themselves operating multiple gardening tools simultaneously. You know how many I found? None. Zip. Zilch. — you know why? Because the likelihood of doing it … safely … is very very low. I tossed the safely in there because someone may have tried, but the pictures were probably pretty gruesome)

So my lawn-mowing business, as a one-man operation is doomed because of limited manual dexterity. I can’t do all (or really any) of the tasks at the same time. What if I multi-task the other way — via task switching?

Since I can’t actually perform multiple complex tasks at the same time, the only thing I could do is task-switch between them. Push the mower a few feet, then go back and trim the area I just mowed, then if necessary, blow the glass clippings off the walk, then push the mower again. Lather, rinse, repeat. Over and over. Does that sound efficient? Or effective? In case you think so, consider this one question: Should I stop the mower every time I pick up the trimmer? If not, I’m wasting gas. If so, I need to take time to restart it when I re-engage the mowing task. The cost of task switching is real.

We have a term for this concept of multi-tasking in the agile world. Any task that has begun is “Work in Process” a.k.a. WIP. When you are focused on a single task, it has 100% of your attention, and our assumption is that you’ll finish that task as quickly as possible because of that dedicated attention. If you have more than one task in progress at a given time, you will only be able to make progress by task-switching.

There are some Project Managers out there who think that if they assign 3 tasks to a single person, they will get executed like figure 6.1. Where one task flows instantaneously into the next.

Figure 6.1 – The multi-tasking myth: No loss of productivity

Unfortunately, brain science tells us there is a cost in moving from one task to another. Conventional wisdom says it is approximately 20%, but some studies show the cost could be as high as 40% or even 50%. Figure 6.2 shows the more conservative 20% value. (Think about the impact this could have on your project schedule if you fail to take it into account).

Figure 6.2 – 20% penalty for three consecutive tasks

I’ve seen some organizations that think they are addressing this by just allocating people at 80% to their projects. But as you’ll see, this may not be enough.

Since we’re talking about our lawn care tasks, we’ve identified three distinct tasks: Mowing, Trimming, Cleanup. To illustrate the impact of multitasking, let’s consider each of those three tasks getting divided between the front yard, and the back yard. Do all three tasks for the front of the house, then repeat them for the back. The second row in Figure 6.3 shows how much that 20% time penalty adds up for a single person trying to do all three things. The third row shows how ridiculous it gets with even more subdivision of work:

Figure 6.3 – One Person, Three Tasks

Note, that by multitasking, you will appear to make progress on all three tasks, but not as quickly as if you did them independently. Every time you switch between tasks, you lose a little productivity as your brain buffers one task and activates the other. Or in our mowing example, as you shut off the mower, walk back to the place you left the trimmer, adjust your safety goggles, then begin trimming until you catch up to the mower. Then go back and find the leaf-blower, swap its cord with the trimmer, and blow the sidewalk clear up until you reach the mower and trimmer. This is illustrated in Figure 6.3. The more you switch, the more time you lose.

The point here. Multitasking is very, very difficult – and the more complex the problem, the less likely you’ll be able to effectively task switch. The only way you could pull this off is if you had more than one brain. Hey! Wait a second…every member of your team has their own brain…

Which means multiple things can be accomplished by a team simply by dividing the work among the team members! Each member of the team can safely handle one complex task at a time with complete focus. And they can collectively perform those multiple tasks concurrently.

Figure 6.4 – Three People / Three Tasks

As you can see in Figure 6.4, by dividing the work between multiple people, you avoid inserting the multitasking penalty into your work. This is why Ed’s time estimates are so low. His team is bigger, and therefore use concurrent actions to eliminate waste on the job!

How many times have you heard someone tell you they are assigning something to a single person because it’s more efficient? Hopefully this gives you a reason to question that assertion.

If I Had a Tractor – Part 5

Agile Estimation and Planning

Part 5 – Cross-Functional Teams

Let’s assume you’re someone who’s going to fund the mowing of lawns.  Maybe you’re the head of the homeowners association, and you’re in the process of subcontracting the upkeep of lawns in the subdivision.  My team originally pledged 16 points, and my competition pledged 60 points.  But after you saw the additional services they were providing, you requested that we have a uniform Definition of Done across both teams.  This threatens to tank my performance.

How could we reconcile this?  You would be well within your rights to ask me, “What can you do, to maintain the higher, originally committed velocity?”

A few ideas come to mind:

Firstly, I suppose I could throw caution to the wind, and try running behind the mower!  I might be able to bring the time it takes to mow each lawn down a bit. But I’ll be honest, I’m probably going to miss some spots.  I don’t think that will ultimately solve the problem.

Secondly, I could work overtime, mowing long into the evening hours.  That has potential, but now I’m going to get way more tired, and likely make mistakes.  The quality of my work will certainly suffer, and I now incur the risk of the customer rejecting the work.  What else could I do?

Or thirdly, what if I try adding people to my team to handle these other tasks in the Definition of Done.  Remember, Ed has a cross-functional team (mower, trimmer, sweeper), where I had only a single generalist on my team).  If I got someone to run the weed-wacker while I mowed, and then whichever one of us finished their job first, swept the sidewalk then I might be able to bring my clock time down to under an hour.  The math would support us saying we could reach 8 points per day then, but I’d still feel a lot better calling it 6 or maybe 7.  Either way my Velocity for the weekend could increase from a around 7 if I go it alone, to a real possibility of 12-14.  Not quite 16, but let’s face it: when I was just mowing the lawn, there was still long grass growing against the fence and the planting beds that the mower just couldn’t reach.  There was still grass clippings on the sidewalk, and let’s not even talk about the edging! In short, my quality was low, and the other team revealed that fact to the stakeholder.  I had to adapt or risk losing the gig.  So I expanded my team.

This notion of a cross-functional team is very powerful.  It allows us to build teams with all the skills needed to achieve our Definition of Done in one iteration, without relying on outside help.

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.

If I Had a Tractor – Part 3

Agile Estimation and Planning

Part 3 – Definition of Done

Something else happened when I hired Ed to mow my lawn.  He brought friends.  Not only was Ed mowing my lawn, but he had another guy with a gas-powered trimmer and yet another guy with a leaf-blower helping him.   So when he was “Done” with my lawn, not only had he completed the mowing job in less time, but he had DONE MORE than I ever did in my 45 minutes.  Trimming!  Edging!  Cleanup!  And once my wife realized those were on the table, those all became desirable additions to my lawn mowing regimen as well!  It was no longer sufficient for me to just gas up my mulching mower and try to get as close as I could to the flower beds.  I needed to pull out my electric trimmer, and follow myself around the yard, then edge the sidewalk, and then make sure I swept the sidewalk and driveway.  Guess what!  My 45-minute job wasn’t 45 minutes anymore!  Ed has a team of three people.  My team still only has me on it.  All that additional work added another hour to the time it takes me to complete a typical 1-point lawn (thanks a lot, Ed).

I ask again.  Think carefully.  Has the lawn changed size, now?  I’m doing so much more to deliver the same job.  Surely the added activities affect the size of the job… right?


The lawn is still the same lawn it always was.  But the definition of what constitutes a completed, quality job has certainly changed!  And because I now need to do more things to complete the same sized lawn, my rate of delivery will go down. In order to maintain the new quality benchmark, I will get fewer lawns done.

Understanding this distinction is absolutely key!  The job didn’t change size; the level of expectation changed, and my team failed to adapt to that change.  The result was a measurable impact on my ability to deliver value and quality (completed lawns).

Why would I insist on looking at it this way?  Consider this:  Recall, earlier I had estimated that I could deliver 16 points of lawns in a weekend — sixteen lawns just like mine.  In order to compete with Ed’s lawn service, I can no longer get away with a mow-only task list.  I need to perform the same quality tasks that Ed provides!  If I equated size to time, I would now have to re-estimate all of the lawns in my list!  Instead of 45 minutes, they’re taking 45+60=105 minutes.  By that magic conversion factor of 1 point = 45 minutes, those 1 point lawns in my neighborhood are now 2.33 points each (because math).  The corner lots are now 4.66 and the weird lot is a whopping 6.99.

Also, since you already had the calculator out, the project manager / mathematicians went even further: “By my calculations, in the same 16 hour work weekend, you can now to do (16 hours x 60 minutes per hour ) / 105 (minutes per lawn) = 9 lawns. 

See how easy this is?  You changed the scale and did math again, trying to force me to commit to something like (2.33 x 9 = 20.97 — aw heck, let’s say 21 points).  Shame on you! Put that thing down before you hurt somebody!

When a 1-point lawn was 45 minutes, you demanded 21 points, even though I was only willing to commit to 16.  Now that a 1-point lawn is (apparently) 105 minutes, you still want 21 points.  Except that before, that 21 points would have delivered 21 pieces of customer value, and now that same 21 points is only delivering 9 pieces.  My team appears to have maintained velocity (that’s good, right?), but we’re not advancing anywhere near that rate!  Only 9 customers are able to be satisfied by the same “21” points.

Also keep in mind, that I’m still not accepting your math.  I was only willing to commit to 16 points per weekend.  And I’m not going to re-estimate everything on my backlog, either.  THE LAWNS DIDN’T CHANGE SIZE!

With the impact the new Definition of Done is bringing to the table, unless I do something to correct my team makeup, you’re going to see my velocity drop like a stone to 7 points – seven lawns instead of sixteen.  And that very rightly should set off a red flag somewhere.

If I Had a Tractor – Part 2

Agile Estimation and Planning

Part 2 – Scope

At this moment, all I have is a cursory understanding of how a few pieces of work relate to one another.  There are a myriad of activities that one could perform in support of a lawn.  We’re going to focus initially on mowing.

One weekend not so long ago, I looked at a long list of activities I needed to work on, and was trying to figure out how much I could do with the time I had.  One of the things that I have a pretty good handle on is mowing my lawn.  My definition of “Done” was pretty basic: gas up the mower, make sure it was set to “mulch”, and wander the property until all the grass was a nice, mostly uniform height. On most weekends, using my self-propelled lawnmower, I have been able to complete that job in about 45 minutes.

Figure 2.1 – My Lawn Mower

“Ah HA!”, I hear you cry, “Time!  Your one point lawn takes 45 minutes.  I’ve cracked the code!”

Well.  That’s nice.  Good for you!  But before you pat yourself on the back and start dividing my backlog into 45-minute increments, I’m going to wrinkle this up for you a bit.

Last summer, I hired someone to mow my lawn for me.  Don’t judge.  Work was demanding, and it was hot, and once you hire one of those guys, they keep coming back.  So my point is this:  Ed didn’t have a measly self-propelled walk-behind mower.  No.  He had one of those zero-turn-radius, stand/ride-behind monster machines that goes zero to sixty in about 2 seconds.  He fired that bad boy up, and viola! My lawn was freshly shorn in 10 minutes!

Figure 2.2 – Ed’s Lawn Mower

So, let me ask you this: Did my lawn change size?  If you are a proponent of a universal constant between time and size, then we’re in trouble. By your calculation, Ed’s performance has reduced my 1 point story to something under a quarter point.

I submit to you that my lawn is in fact, the exact same postage stamp it has always been.  If it was 1 point before, it is 1 point now.  But something is clearly different.  Even I have to admit that 45 minutes vs. 10 is pretty compelling (or at least disheartening).

The difference has very little to do with the lawn itself.  The difference is that Ed, with his superior machine is capable of delivering the same work in less time than me (or more work in the same time).  If you assume a universal conversion factor exists, then you will need to gather two sets of estimates (mine and Ed’s), or at least pay attention to which one of us gave an estimate for a given lawn.

Or, maybe we try looking at this another way…

If you take my 1-point lawn and assume that every approximately 1-point lawn will take the same approximate amount of time (for me) then I can use that understanding to suggest how many 1-point lawns I believe I could fit into a weekend.  Given what I know, I think I could complete approximately 16 points worth of lawn in a weekend.  But my friend with the impressive hardware can do many more!  The math whizzes out there have probably already concluded that Ed can do six 1-point lawns in an hour.  So given an eight hour workday and two days in a weekend, he’s going to be pounding out 96 points worth of lawns every weekend.  Those same math whizzes will point out that my sixteen-lawn estimate for myself is obviously under-represented.  I should be able to do four lawns every 3 hours, so the same eight hour workday, I should be able to do 21 points worth of lawns in a weekend, and if I just did a little overtime, I could pull off 22!

Isn’t math awesome?

and Terrible?

Allow me to toss a little water on those flames of victory you’re dancing around.  Unless you are going to work things out so those 21 lawns are placed end-to-end next to each other and set up my mower to be perpetually full of gasoline, I can’t possibly attain the number you’ve so carefully calculated for me.  I will have to move the mower from one location to another.  I have to refuel at every job.  I have to stop to take a drink of water, or eat lunch, or answer a call.  Your assumption of my velocity seems to be missing a few considerations. 

Your assumption of Ed’s velocity is just as wrong, by the way.  In order to move that behemoth of his, he needs to load it up onto a trailer and drive it to the next job site.  Where would we account for loading and unloading time?  Where do we account for the travel time between locations?  What about bathroom breaks?

The capability of a team is made up of a lot more than just the sum of the hours of work they perform, or the number of hours we think they can give us.

If I Had a Tractor – Part 1

Agile Estimation and Planning

Part 1 – Size

Let’s go back to the lawn example, and start with a simple explanation as to why time is a terrible way to measure size…

I asked you how big your lawn is. I want you to think of your lawn. Think of the dimensions, think of how much of it is actually available for mowing.  Yes, that’s right. The grass.  Not the driveway.  Not the garden, nor the planting beds.  Not the patio or the stoop.  Got it?  First of all, notice that the size of your lawn is not the size of your lot.  The lot represents the dimensions of your property.  But not all of that is lawn.

Are we good so far?  I don’t want to lose you.

Now.  Picturing your lawn, and only your lawn:  How big is it?  Odds are, unless you’ve played this game before, you can’t give me an exact answer. You probably could if I gave you enough time and a tape measure.  You could probably get me a pretty exact measurement of the lawn part of your property.  But I have two problems with that.  First, it would take too long, and second, that wouldn’t be an estimate anymore, would it?  It would be an actual.  Traditional estimation models excel at doing this (pun intended), by giving you a really long time to lull yourself into a false sense of security in your ability to predict the future.  You may have noticed this activity is often followed later by a check of how accurate your estimate was — or more to the point, how wrong you were.  “We gave you months to predict the future! Why were you unable to give us a better estimate?”  That’s a hell of a way to start a conversation, isn’t it?  Let’s try to accentuate the positive a little, shall we?

In a moment we’ll get back to talking about the size of your lawn…by comparing it to something else!  Studies have shown that while humans are pretty bad at exact estimates, they are very good at comparing things.  This is a survival skill you learned as a small child – especially if you had siblings.  Remember family deserts?  Remember when there was one piece of cake left and both you and your pesky brother (or sister) wanted it? Remember how your mother, with the wisdom of Solomon, suggested you split the piece? The rules were simple: One of you sliced.  The other one chose – which gave you all sorts of incentive to slice well.  But no matter how carefully the slicing was carried out, one piece wound up slightly bigger than the other one and I’ll wager my half of the cake that you could tell exactly which half was bigger (the one you wanted), just by looking at it.  Or perhaps, they were actually close enough that there was no real distinction between them, and you both got to eat a piece of cake with satisfaction of knowing nobody got cheated.  We are going to leverage this skill in Agile Estimation.  The ability to look at two things, and declare whether one is bigger or smaller will prove valuable here!

Ready?  Do you need some cake first?  We don’t have time for cake.  Cake is for closers.  Are you a closer?  Let’s see what you’ve got.

Think about your neighbor’s lawn.  Let’s see if you can answer a simple relative sizing question.  Is your neighbor’s lawn, bigger, smaller, or about the same size as yours?  If you live in the suburbs this part will be really easy. Odds are pretty good that your neighbor not only has the same size lot as you, they probably also have a similar amount of grass in their yard.

So, what’s your answer? Is one lawn bigger than the other? Or perhaps, they’re close enough that you’re willing to call them even.  We’re talking now about degree of precision. When we ask for estimates, we should not be asking for perfection.  We just want to know within a margin of error.

To make this next part easier, I’m going to switch to talking about myself for a sec, partly because I’m having trouble seeing your lawn, but also because my neighborhood provides a particularly compelling example.

I can say with a fairly good degree of certainty that not only do I and my two adjacent neighbors have similar-sized lots, but the amount of open grass is pretty similar between the two — close enough at any rate.  That means, in terms of relative sizing, our three lawns are the same size.  How big is that?  Not sure yet, let’s think a bit farther.

Now think about your neighborhood, and the finite universe of houses and lawns that surround you.  Can you think of any lawns smaller than yours?  Can you think of any that are bigger?  If you can answer ‘yes’ to either of those questions, then the next question will be “How Much Bigger, or How Much Smaller”, and because we haven’t established a unit of measurement yet, let’s just use relative sizes.

Returning to my yard, the houses in the middle of the block all have the same lot size.  I also can’t think of any houses in the area with a smaller yard; but I can think of a few yards on the corners that are bigger… almost twice as big!  And then if I think about all the houses on the block, there is one house that due to the curve of the road, I’m pretty sure his lawn is closer to triple the size of mine.

I’m going to establish an arbitrary starting point now.  Based on my understanding so far, my yard and my neighbors’ are all 1 point yards, the corner houses have 2-point yards, and the odd-shaped yard a 3-point yard.  The chief advantage at this point, is this measurement was FAST.  Not a lot of time spent agonizing over it.  It was a quick 1,2, 3 and we’re ready to move on.

Figure 1.1

I now have three data points we can use to compare other work to.  If someone asks me over to their house and say, “could you estimate my lawn?”, I need only look at it, and compare it against the three data points in my head.  Is the new lawn bigger, smaller or about the same as one of those other lawns.  And if it is bigger or smaller, how much so?

The other advantage is that this estimate is PORTABLE – meaning it can be applied to the work of more than one team.  We’ll start to see why that’s important in the next section.