4 Sherpas took an adventure to Toronto for the Full Stack Toronto Conference 2015, these are some of the things they learned...
As with most irritations in life, certain ones never change:
“When is dinner going to be ready?”, “When are you going to get here?”, and my
least favourite, “How long will completing this task/project take you?”
The easy answer – “I DON’T KNOW.” There are too many
variables involved to give you a straight answer, and only when you are an old,
tired developer will you be able to look at something and say, “2 days, less if
I don’t eat lunch.”
We all know that “idk” is not an acceptable response for
anyone who pays your salary so you have to give them a number. And this number
you give them is a promise that you will try to uphold when it comes to
completion.
So how do you get that number?
Cohn scale estimations and the cone of uncertainty to better
represent time estimations.
People are inherently bad at judging quantity and
measurements. Guessing the volume of a glass is nearly impossible; however,
judging relative size is much simpler. A small glass holds less than a medium
glass, and a medium glass holds less than a large glass, and so on and so on
and so on.
The Cohn Scale is a method of applying relative
size values to tasks or user stories instead of assigning time to them.
Therefore, something is no longer 3 hours to complete, it’s an 8 or a 5.
The scale ranges from 0.5 to 100 and encompasses upwards of
50% “forgiveness” in either direction. This means that a 5 could be a 3 or it
could be an 8 in actuality. But in the grand scheme of things, this is an
allowable level of “failure” since Laws of Average dictate balance throughout
project sprints (that 5 was actually an 8? no big deal, all those 3’s were
actually 0.5’s – Saul Goodman!).
Democratically these points can be assigned to user stories.
There is a method called “Planning Poker” that works as a table meeting where
(almost) everyone involved selects the value they believe the story should
take, and discuss why they believe this – then if there are any differences,
they do it again until a single value is selected for the story.
However, if you are a lone wolf, give it your best guess
based on previous experience with the story, have you done anything like it
before? Have you already developed something that you can steal from? Is it a
trivial item that will easily get done while you eat lunch or will it be
something that you will have to research first?
Once you have all your stories or tasks assigned with story
points, you can now continue.
The cone of uncertainty is nothing like the cone of shame, and unless you are a Gypsy Fortuneteller, you have no real clue how things are
going to pan out for anyone. The only true certainty is that nothing is
certain. And if anything, Murphy’s Law is going to present itself in your
project scope somewhere.
The cone was developed back in the 80’s and it shows how
closely you can estimate given the current stage of development. This has been
altered slightly to adapt to Agile management procedures since it was
originally designed with Waterfall management in mind and now uses sprints as
markers instead of stages.
Early sprints will have the widest range of uncertainty
whereas later sprints will be more accurate. It’s pretty simple really. At the
beginning, you know nothing – later on, you gather all that time + XP and you
know when you are done.
Let’s get to that number already. This is the formula, by
substituting the uncertainty value with both sides of the cone you get your
lower and upper values. Put together how many story points you can do within
your sprint length, tally up the remaining story points for your velocity, and
start calculating.
And that’s pretty much it. Report back with the range of
time it will take you, and this is the best estimate you can give. The only way
to get any narrower is to start working on it.