Continuing in the estimate world, I would like to propose a form of estimation that I think has been lost over the years in the wake of scrum’s rise to power in agile. I personally don’t care if you use points, days, hours, ideal days, or even no estimates and just use throughput. This is an approach I like. Get your bias ready… Here we go…
This entire approach is focused on making things small enough that you could somewhat estimate it accurately. People are not good at estimating large things or far out dates. Don’t try and do that. On top of that, no one should feel pressured to give smaller estimates. Furthermore, no on should feel pressured to commit to a “done” date if they aren’t reasonably comfortable they can get there.
Comparative estimation is a practice of taking items you have already done, looking at the complexity of them and the time it took to complete. Then take your new item and compare it to that item. So crazy it might just work.
This is not a new technique at all, I just think it has been forgotten over the years. I was ignorant, for lack of a better word, in my younger years. Thinking I could come up with some technique all on my own for estimating software that nobody had thought of. I even thought I was quite smart when I first said, “Hey, this thing we are trying to do, does it compare to anything we have ever done before?” I thought I was really onto something. Then in my attempts to improve my knowledge of software development best practices, I came across a number of books on Extreme Programming. In Ron Jeffries “Extreme Programming Installed” was a chapter on Story Estimation. And there it was, a section on comparative estimation. My immediate response was, “Wow, I’m not crazy, but I am also not so original.”
This is a pretty simple concept that I am sure by now you have already figured out. But here are some of the questions that help to get that comparative estimate when working on a project.
- Does this story seem like any other story we already did?
- Does this story have any special pieces that we have never done?
- Does this story touch the database in anyway that is similar to another story?
As Ron Jeffries states, an Aha moment will occur when you say “This is just like…”
Now think about if this new story is easier or harder than the one you are comparing it too. Have that conversation and make a decision of the estimate to give the story. It is important to consider the teams current situation as well.
And it really is that simple. It is also smart to consider these additional questions.
- Is anyone out of office during this iteration?
- Do we have less development time in favor of support?
- Was the team drastically different when we built the comparative story?
SPIKES are also very useful when struggling to estimate a story we really don’t understand. SPIKES are used to complete some research on the story. I like to use SPIKES to meet with customers and users and walk through their problem and steps they can take to resolve them. This usually results in what is referred to as a story map. This is not meant to be the full detailed solution, it is meant to be the tasks needed to complete the objective simply laid out in some sequential order the user will follow. This allows us to have a visual representation and create a shared understanding of what needs to be done to implement that story. Take the details from the SPIKE and use that to better understand the story, discuss the tasks that it will take to build that story and then estimate it.
Estimation may be a necessary evil. But there is something to be said for the #NoEstimates movement. If you are forced to estimate however, I would not use story points, or time, I would use a scale of something valuable that I saw Allen Holub promote during a talk.
- Trivial
- Easy
- Normal
- Hard
- Herculean
- Don’t Know
I feel like this provides enough information to really know what it will take to get something done. And the use of story mapping, on-site customer, and continuous delivery really diminishes the value of estimation.
We can still make projections simply by counting stories. If you have time, I would recommend watching this talk by Allen Holub.
Eventually we will come to the reality that some things just take longer to build then others. People working under pressure make mistakes and cut corners. Leaving behind a mess of code for either themselves or the next developer. Who by the way is now under that same pressure and a big mess to deal with. And just for a bonus, we usually slip that pressure date and it doesn’t work as intended so you have now successfully sacrificed quality for speed.
No matter the estimation technique you choose, the important part to remember is big things are hard to estimate with any form of accuracy. Small things are much easier to estimate. Break big things into small things, then estimate the small things. Or, break big things into small things and work with your customer or user to deliver them.
Chris Pipito 