Story Points, Bugs & asking yourself “To What End?”

Some people like to invent complication. I’ve noticed this a lot when it comes to agile software development among teams that are following the fashion without really understanding what they are doing, or why they are doing it; and it doesn’t help that since seventeen or so guys met up in a ski resort in Utah over ten years ago, a whole cottage industry has sprung up around agile coaching & training – of which I’m certain a significant number lean more towards being snake-oil salesmen selling ‘Agile’ the noun (as Dave Thomas – an original signatory of the agile manifesto – laments here).

I’ve got a few ‘Agile’ items in my backlog to moan about later, but for now I wanted to talk about a particular irritation – story points & bugs. I keep finding myself in discussions with people asking what is the proper way to estimate bugs? Often this apparent difficulty stems from the idea that story points represent business value deliverable to the client – and as such we shouldn’t assign story points to bug fixes because they are mistakes, rather than value to the client and that our velocity should only reflect our ability to deliver value to the client, rather than our ability to clean up after ourselves when we mess up. Here are a few quotes for clarity:

“Our theory is that points, and our resulting velocity, should demonstrate business value to our customers. Customers shouldn’t “pay” for bug fixes. The product should be of a valuable quality.”

“Hone skills for collaborating with the customer. Story points represent what the customer values. Better to hone the skill of writing and estimating stories, as the vehicle for delivering that value, instead of trying to figure out the convoluted ways to write a story about fixing a memory leak.”

“I don’t assign story points to defects since I think story points are a measure of the team’s ability to deliver value in an iteration. Fixing defects, while important and valuable, is NOT delivering value…it’s a drag on the team’s ability to deliver value. The more the quality is built in –> the less defects arise –> the more bandwidth the team has to deliver new stories –> the velocity should be seen to increase. Assigning story points to defects, I think, pollutes this.”

“…fixing defects, while important and valuable, is NOT delivering value…insomuch as value is measured as quality product in the hands of customers. If we’re using story points to measure our effort to make ANY changes to the product, be it new functionality or fixing defects, then have at it and assign story points to defects.

If we’re using it as a measure of a team’s ability to deliver high quality product into the hands of the customer (my preference), then no, don’t assign story points to defect work.”

 

I think that the common theme here that underlies the misunderstanding of story points is the apparent misunderstanding of the term ‘business value’. I think that this is often the case because people have failed to ask themselves the most important question anyone should always ask when developing software – to what end? Perhaps the dark side of the previously mentioned cottage-industry preys on those that are quicker to buy a productised – step by step – solution than they are to wonder: ‘to what end?’ and in the process grok the rationale behind agile development methodologies and principles. Give a man to fish and he’ll eat that evening; Send him on an Certified ScrumMaster course and he’ll progenate a team of jaded and cynical developers who feel no joy in their supposed agility – thanks to the nagging dissonance associated with constantly trying to resolve contradictions which needn’t exist if they only knew ‘to what end?’ they were adopting these methods & techniques, and with that understanding were able to choose and apply them appropriately.

 

Hold on – ‘Bug’ is a pretty ambiguous term…

Yes it is. So to put this post in context, we’re talking about generally well defined defects that have managed to be introduced in a sprint and have found their way outside despite the associated stories being ‘done’. We’re talking about bugs that should have been caught, as opposed to the kind that only manifest themselves when a butterfly flaps its wings a certain way.

Other kinds of bugs include those of similar origin, but which aren’t well understood or defined – these would likely require a spike as it would make no sense to relatively size a poorly understood problem. Although there’s no reason that spike couldn’t spawn point-estimated task if it was worth doing so.

One last scenario worth mentioning is bugs not introduced during a sprint, but the kind that might exist in a backlog to address defects in an existing legacy system. Lets assume that these are all well understood by now so that we don’t need spikes. Should we assign story points to these? No – these probably shouldn’t even be part of the Scrum (i’m assuming Scrum as it’s pretty ubiquitous these days) paradigm – particularly if they are all individual and discrete issues (as they typically are). Why on earth would we think that Scrum or even ‘Agile’ (the noun) is particularly appropriate? To what end would we introduce such a framework?

That’s the subject of another rant I’ll get around to sometime, but to cut a long story short we use agile methods and techniques to achieve a state of agility in the business:

  • Agility to respond to change in a dynamic global market.
  • Agility to fail fast and fail cheap.
  • Agility to minimise time to market in order to maximise return on investment.

 

Those kinds of bug fixes, as discrete individual items, don’t participate in the tight feedback loops that facilitate such agility in the first place. How will Scrum, when fixing these defects, help us to achieve those attributes of agility?

 

To What End?

Story points exist to decouple our estimation process from units of time. It’s as simple as that. Why?

We live our lives in hours and days, and our sprints (if we’re using something like Scrum) are measured in aggregations of those days. Our releases are probably planned in aggregations of those sprints, etc. These are all fixed measurements and their relations, in a quantitative sense, always remain fixed relative to each other (except for leap years perhaps!); The problem that this poses is that it makes it incredibly difficult to estimate accurately (in hours for example), over an extended period of time with all kinds of changing factors which influence our ability to deliver value to the client, just how much value we can deliver in any given timeframe.

If we can decouple our estimations from units of time we can decouple our ability to give useful estimates from the factors that effect the time it takes to deliver – team alterations, changing product complexity, increasing productivity with familiarity, physical environmental factors, or anything else you might imagine.

By sizing stories relative to one another, using points, we can measure our velocity – our ability to deliver value to the client – in a way which is self-correcting without ever having to estimate anything other than how large one story is compared to another.

Different people in different teams can all easily estimate, with reasonable accuracy, the size of one story compared to another – regardless of how long it would actually take each of them to implement those stories compared to their colleagues. With a little effort and discipline we can have discrete teams with different velocities, all normalised according to a common understanding of story point allocation; This grants a product owner otherwise unimaginable flexibility when it comes to planning and allocating stories to multiple teams.

 

So this is the ‘end’ I alluded to when we wondered what story points were used for. So to what end would we conclude that story points shouldn’t be used to estimate bug fixes?

 

Business Value

Simply put, business value is something that the client wants. Something that the client cares about. Something they value.

The client doesn’t care whether you need to spend time upgrading your development machines to the latest OS version, or whether you need to spend 15 minutes every day rebooting your flakey git repo, or whether you need to spend more time testing because quality is slipping (a new screen roughly similar to a previously built screen is worth roughly the same to him whether you spend twice the time or half the time).

Your client DOES care about getting stories delivered, and your client DOES care about emergent bugs being fixed (hence bug fixes do provide business value – otherwise your client wouldn’t care whether you fixed it or not).

With this clearer understanding of business value, is there any end to which you can imagine that not assigning story points to estimate bugs will be beneficial? Lots of people like to assign a spike instead. The trouble with this is that (in the context which I set out earlier) the bug definitely needs to be fixed, and spikes are by definition time boxed efforts (which implies that bug resolution is optional). Secondly, which ever word you use to describe the allocation of resource involves an implicit conversion from time to story points – otherwise how do we know how many points fewer to commit to this sprint? The point of time-boxing spikes is that it makes no sense to try to size them relative to the usual stories; If it does make sense to compare them to the size of stories, then it almost certainly shouldn’t be a spike. The only reason to do so would be to accommodate this faulty ‘bug fixes aren’t business value’ logic.

 

How I would account for Bugs

In the context outlined earlier, I like to keep it as simple as possible unless there is a compelling reason not to. I would size the bug relative to other stories as usual – lets say we think that it will be roughly 2 points. It’s important that we assign these two points because they represent work that needs to be done, which means that there is 2 points worth of other work that won’t fit into the sprint.

We also need to remember that the original story from which this bug leaked (if we can pin it down like that) was estimated with a definition of done which, presumably, implied that the deliverable was bug-free. The fact that we’re now addressing that bug means that the original story isn’t in fact complete, and if we kept our velocity as it is we would go into our next sprint estimating how much work we can ‘nearly finish’, rather than actually finish (especially if this bug leakage is becoming habitual – otherwise in a one off situation this may not be worth the bother). So I’d reduce our velocity by 2 points, for example, too. That means that this sprint we’ll actually plan to deliver 4 points-worth fewer stories, and then going forward our velocity will be 2 points less until such time that we stop leaking bugs and manage to gain some velocity back.

 

This entry was posted in software and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s