Saturday, 16 March 2013

Story Points are Quantitative ... well kind of

One of the most fervent, ongoing dichotomies I continue to hear about is that of defining Story Points; SPs for the remainder of this post. This includes a Q&A discussion on a recent webinar I attended. The frustrating part of me is that this dichotomy is a justification in some people’s minds on why Agile is an immature methodology. Thus, the reason for this post.

As fervent as both sides of this debate are about whether or not Story Points (SPs) translate into time / effort / duration tangible numbers. The reality is that they're both correct. I can hear the gasps, gfaws, angry mind squirrels seeking the comment area now! What! How ridiculous!  To that, I say "LOL". :D

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.