My wife hates it when we need to go somewhere and I’m in the middle of something. In this scenario, I’m usually into whatever I’m doing up to my elbows and running late. The conversation usually goes like this….
“How much longer do you think this will take?” my wife asks.
“Ten minutes or so…” I’ll reply....
½ hour later, I’m still not ready, and my wife is not amused.
The issue here is not that I’m lying. The problem is that we humans are terrible at estimating how long it will take to do something. Think of it this way – How big of a job would it be for you to paint your living room?
Note that I didn’t ask you how long it would take or what you had to do to get the job done. All I want to know is how big the job is.
So…. let’s say that we say that painting the living room is a large job.
Knowing this, how big of a job is painting the master bedroom?
Welcome to Agile sizing
So why do we do sizing and planning the way we do in Agile? I mean, doesn’t it make more sense to meticulously plan everything out?
Not really
The reason we use what may be considered an inexact process to determine how much work can be done by a team is how stories and/or tasks relate to each other. In something as complex as a development cycle, it’s a safe bet that stories and tasks do not stand alone. They relate to each other. In other words…you normally don’t work on story 3. You usually have to finish story one and part of story two before you can start story 3
Knowing this, when one story takes longer than expected to complete, it is not reasonable to say that another related story in the sprint will take less time – the reality is that usually all remaining tasks will take longer.
As long as you are consistent in how you size your stories, everything will work out fine.
Mike Cohn from Mountain Goat software puts it this way
“It’s better to be roughly right than precisely wrong.”
The big lesson here is that you can be extremely precise and miss your target completely.
I’ll use another one of Mike’s examples. My daughter Jorden had a birthday last month. An accurate statement would be that Jorden's birthday is in May. This gives you what you need to handle the situation. For example, if you were going to mail her a birthday card, you know when you would need to mail it. A very precise statement would be that Jorden's birthday is on January 1st at 4:15 pm. That is a very precise statement. The problem is that it’s precisely wrong…
Back in the waterfall days, we attempted to be precise about how long it would take us to implement features in a release. Due to things like human nature and changing requirements, those plans rarely were truly accurate.
Agile is more focused on planning than the plan itself. The benefit is in the estimating activity. The collaboration process allows everybody on the team to share what they think. Somebody will think that a story is large, but somebody else thinks it’s a medium. This should lead to a team discussion about the story and why it’s either medium or large. In an Agile world, it’s always about the team. So many times in the past, planning was done as individuals. Now, the team can be creative and innovative. We expect things to change – in fact, our planning needs to encourage change. Agile estimating and planning enable us to do this.
This is the biggest benefit of estimation. I know that some say estimation is a waste of time (#NoEstimates, anyone?). I'm not one that lives in a world of absolutes. For some teams, estimation might be a waste of time. For most teams that I've worked with, estimation was super valuable. Do what makes sense, then inspect and adapt.
Go forth and Be Agile.
