As
fervent as both sides of this debate are about whether or not Story Points
Seriously,
the whole point of story points is not to have just another way of saying how
much work there is to do! Yup, you heard me! It's not some conspiracy to create
even more and new overhead. It's about creating visibility of scale to get
people moving forward on something that will create something tangible and of
benefit to customers, users, and yes even the company who hired people to
develop, test, document, release, market and sell it.
Okay,
let's get into the weeds of this debate shall we?
Dichotomy side 1: SPs Have No Time Correlations
Let's
start with the side that say SPs are qualitative numbers and have no
correlation to time. In this camp, it's all about T-shirt sizes, H / M / L
categories, etc. The SP cards might as well be colors as Fibonacci numbers.
These are the people who prefer to say "I'll tell you how long it's going
to take when I'm done." or at least "I can't tell you until I've
burned through 2 to 4 sprints and have an average of how many SPs we can get to
'Done" in a typical cycle / sprint / iteration.
The down
side with this approach, that I've found anyway, is that it presumes everyone
estimating (playing planning poker) has a similar scale of how much effort will
be required to get the work done. I've actually seen scenarios where everyone
agreed a story was a size of '1', told the guy in the room saying "hey,
wait a minute ..." that he was just wasting their time, and then the
testers asking the developers the next day if they'd have the build (that's
right kiddies 'the' build, not 'a' build, 'the' build) for them
by the end of the day. That was the point where the communications regressed
into something less than respectful because the developers meant "one
sprint" when they said '1'. Of course, this cascaded into problems where
the testers had put something else on the back burner, wouldn't be available at
the end sprint (in 3 weeks), and couldn't be expected to just sit around until
then! You see the picture, right? :-)
This
hasn't ever happened to you; you say? Great! Congratulations! Could you perhaps
add a "yet" onto the end of that sentence? Okay, enough of this
side. Let's move over to the camp of people who say "everything must be
quantifiable to mean anything; otherwise it's just a waste of their time!"
Dichotomy side 2: SPs Correlate to Effort
These are
the people who typically have tight budgets, are in consulting, professional
services groups, etc. Because quite frankly, nobody is interested in working
for free. Not even the junior engineers in the other camp who want to tell you
how long it will take when they're done. Let's look at this a little more
closely shall we? The fact is, quantifiable numbers enable people to think
about how long (when it will be ready), how much $$$ so they can pay bills,
wages, etc to be around for the next contract. Ever run into a scenario where
somebody delivered something 6 weeks late and was incredulous when nobody
cared? The fact is they missed the boat and this is what exists a lot of the
time in business. It's about both realistic and ideal costs and durations /
days required to get something to 'done'.
The Rule of 1.x
Sometimes telling someone that a story point equals a day will just
get them thinking 'Agile' is 'a Guile' and BS and waterfall just using
different words. That’s why I prefer to get the team thinking about the work
involved rather than how much effort it will take.
On really unclear, breaking new ground
types of initiatives you may well just need to start off with high, medium and
low sizing; very small, small, ... XXL T-shirt size estimates. And yet no one
in their right mind is going to give you a budget based on that. No one will
ever go in front of a group of executives to say please give me a million
dollars, we believe the project is 22 Medium t shirts big. Amazingly
though I’ve had experiences in my career where some people thought that was
exactly what we should. This is only your first step to get to some focus on
some subset of your backlog to get some quantitative numbers. A break down of the
work into its component subsets (or some smaller, manageable chunk) until you
get to a point where you've got a list of tasks so you can say if Bob does
this, Mary does that, and Pat does this other thing we'll be able to demo for
you our version of the newest product with this subset of specific
capabilities.
If your
team has a velocity of 10 SPs in sprint 1, 8 SPs in sprint 2, and 12 SPs and
the team worked the same way, same number of days, etc it doesn’t mean you did
anything wrong. It means you can expect to burndown 10 SPs per sprint on
average. It may also mean that some of the estimates were off by 20% and just
like in a bell curve everything just averages out, and that instead of planning
out everything over a mind-numbing 3 to 6 weeks to the n-th degree of detail
you have enough information after just a couple of days to tell the business
when they’ll get their software, and the developers, testers and tech writers,
etc can get onto what they do and love best.
The above
is why I like to say SPs follow the rule
of 1.x.
A Word of Caution
Sometimes to people getting it their
heads that “oh well, it was just a estimate”; “I can come up with any number off
the top of my head and say oops later”. No skin off my back; right? No, not
right. Think about it in terms of an example that I think most of us can relate
to, and maybe even some have experienced themselves. If you went to a garage to
get your car fixed, they called you will an estimate of $200 and when you got
there they handed a bill for $1150 and said “Oh well, was just an estimate”
you'd probably either go ballistic or vow to never go there again. Now, when
your estimates to develop a new feature are way off, this is what they’re
thinking about you. This is what I'm talking about when it comes to holding
a planning poker exercise. For me, if I didn't expect you to take the work
seriously, I could more easily just come up with the numbers myself using a
random number generator and then blame you when you couldn't hit those probably
ridiculous estimates. Of course, if that was the case you wouldn't want to work
with me either. This is what is meant by mutual respect in the workplace. I
take what you do seriously and vice-versa.
Sometimes coming up with accurate estimates
is just not possible, or as one manager I know put it, "the only thing
that is clear is that everything is unclear."
So ..... what are we ever to do?
That's easy, if you (and the team) have
come up with story points estimates for everything in your backlog -- pick
something small but not too small, something with an obvious solution but not
too obvious, something of one or a few SPs. If people new to SPs and planning
poker are more comfortable equating 1 SP to a day-ish of total effort among everyone
involved to get whatever to 'done'
try it and see what happens! Seriously, it’s really that simple. If it turns
out to be about a day of work then you probably have some good estimates for
the rest of your backlog. If it turns out to be a week when the team decomposes
the work, you may just want to try this again with something else, expand out
your estimates for everything else by a factor of 3 or 5, or some combination
of these two things and perhaps something else just for good measure. If you’ve
got a team with people who have worked well with each other a lot in the past
and have been involved in the development of the project’s requirements you may
just want to dive right in to your planning poker and estimate your stories.
The above
is certainly not all encompassing on this. That’s why companies need to
formally train existing employees and hire qualified ones. And please excuse me
for saying so if this contrasts with your perspective but quite frankly I’m
going to listen to the original Agilists and those who and widely published
authors over highly charismatic webinar hosts. The following links may help you
get to your next threshold in the use of SPs.
Mike
Cohn’s blog -- http://www.mountaingoatsoftware.com/blog/how-do-story-points-relate-to-hours
Jeff
Sutherland -- http://scrum.jeffsutherland.com/2010/04/story-points-why-are-they-better-than.html
