Dealing with Bugs

The below diagram is the basic flow that I generally adhere to when talking about when should a bug get fixed or not. This is pretty obvious – and far easier to draw than to write out.

Bug flowchart

There are of course some subtleties – the devil often being in those details.

Analysis – this is all about analysis.  Sometimes it is easier to do.  Sometimes someone needs to do some digging to work out the details.  That doesn’t change the decision flow – just that you might need to do more work to get to the decision.

Bug definition – internal issues generally really are bugs as there is usually higher communication around what features and changes are and how to handle those within the team.  For external issues they could be changes, features or plain old bugs.  I assume that that analysis is already done or becomes clear during the process.  No matter what type of issue it is – they are all subject to the same decisions.  It is often easier to put a feature/change straight onto the backlog for later planning.

The problems with not fixing bugs now:

  • One small bug not fixed now isn’t a problem. 100 is.  Don’t naively grow the debt by only looking at the current issue in isolation.
  • Not fixing 10 bugs may signify a more rapid decline in not fixing other issues as it gets easier and easier to justify not fixing something.
  • Not fixing an issue now may underlie a bigger problem.
  • Hanging on to issues that you choose not to fix immediately grows the backlog with low priority issues.  Generally these low priority issues never get prioritised because… they’re low priority!  Be aware of simply growing a long list of things to remember that you’ll always ignore.
  • Make sure that if you decide not to fix something that it doesn’t keep coming back.  This is even more pertinent if the team find it and the PO decides to fix it later or never but then when someone else finds it nearer your release date – for instance in a hardening sprint – and now it needs fixing.  This shows a problem with the initial decision and will cause frustration for all.

Points for bugs – if I plan a bug for a future release I generally consider it a change and want it to be sized.  We’re sizing the effort for the release so we might as well get as much data as possible.  If you’re fixing the bug before the release then at most size it to determine how much you can take into the sprint but don’t take points for it as the number of bugs you’re creating is part of your velocity and the real velocity should drop due to work that isn’t properly done being done again.  The team should acknowledge that.

Learn from the feedback – as in any agile environment – look at what is happening and try to retrospect on why the issue happened and how we could avoid it happening in the future.  What documentation or details could have been shared with the client so that they could have known that what they were asking for isn’t a bug?  What did we miss in our own process that caused it to be a bug?  Sometimes it is too easy to say it was some once off thing but many once off things could also have the same root cause – or the same solution.  Dig a little deeper if everyone simply thinks – well that was due to this one deployment specific issue that now we’ve gone through – it will never happen again.  Because it probably will happen again – in some other form.


Incremental Play

Incremental Change, Working Product

In our recent trip to New Zealand we stayed with a friend in Wellington who has two children near my girl’s ages.  They had a lovely train set which my girls loved.  However the first couple of times they set up the train set they mostly built it in a straight line and then got frustrated when they couldn’t make it loop back on itself and complete the track.

I watched this a couple of times and then, as daddy is an engineer, I landed up helping them build the track one morning.

The key problem is that there are a number of pieces in the set, but it isn’t clear what configurations are supported in order to ensure a closed track.  So I thought I’d try Scrum to solve the problem.

Short iterations

I did not timebox.  That would have been far too geeky.  But we did start by making the simplest possible thing that would work as a closed track.  That was a 4 piece circle.

Working product

I demonstrated this to my stakeholders / product owner (my children) but they weren’t too impressed with my track.  So we iterated – and built it out.  And built it out some more.

Each time we expanded by breaking the track, but fixed it quickly by doing the least work required to create a better, larger, cooler track.


Each time we had a working track the girls would drive the trains along the tracks and test out the ideas and make suggestions for what needed to be included.  The tunnel, the bridge, more side tracks, etc.

Scrum Works!?!

By keeping the track functional as much as possible the girls were able to play at quick, regular intervals all through the process – on many different tracks.  By doing the simplest thing possible we could expand it, inspect and adapt and have a closed working track that maximised the use of all the train set by the time we had finished building it out – which was the business goal for my stakeholders / product owner.

It was SO COOL!!!

I might need to try the lego thing now 😉