Matt Archer's Blog

  • New Book

    I'm working on a new book. View the home page for the 'Tips for manual testers working in an agile environment' book
  • Enter your email address to receive notifications of new posts by email.

  • Subscribe

How to run a bug ‘lucky dip’ after your daily Scrum

Posted by Matt Archer on July 10, 2012

I remember being excited as a child when the opportunity of a ‘lucky dip’ presented itself. The game was simple. A selection of prizes would we wrapped in gift paper and hidden in a barrel of foam beads. One at a time, each child would then ‘dip’ their hand into the barrel and pull out a prize. The prize each child received was solely based on luck. The only certainty was that there was a prize in the barrel for everyone.

With a bug lucky dip, team members perform a similar ritual, the only difference is that there is rarely a barrel involved and team members are rewarded with a specific kind of prize; a bug to fix!

How I perform a bug lucky dip

Five minutes before the daily stand-up (daily scrum) is due to start, I glance at the task boards to gauge the number of bugs that have been recently added, but not yet fixed. If only a few bugs exist on the board, then there is no need for a bug lucky dip and I attend the stand-up as normal.

If, however, I notice a large number of bugs on our task board (especially, a large number on the left-hand side of the board), then it’s time to take action. On my way to the daily stand-up I take a detour via the task board and select as many bugs as there are members of the team. I take the cards that represent the selected bug with me to the daily stand-up.

Once everyone has finished their update at the stand-up I produce the bug cards and lay them face down on a table. If no table is available, I fan the cards in my hand with the text facing downwards. Each team member then takes it in turn to select a bug at random. The aim is then for each team member to fix their randomly selected bug at some point during the day. They decide when it’s convenient.

Why I like bug lucky dips

They’re fun: I find team members can’t help raise a smile at the point that lady-luck helps them pick a bug to fix, especially if that bug is perceived to be particularly simple or complex. I’m sure you can imagine the types of playful comments team members receive when they select a bug like “incorrect font size used on the welcome screen” vs. “memory leak in the mass-email component”. I know bug lucky dips introduce an element of theatre that could be avoided by just randomly assigning bugs to member of the team to fix, but I strongly believe that team bonds are formed just as much through play as through serious work.

They help promote collective code ownership: The bug somebody fixes is entirely based on chance, so you could find yourself making a change anywhere in the code. Similar to pairing, this is a great way for team members to become familiar with every corner of the code and hugely reducing the chance of knowledge walking out of the door when a team member leaves or moves to another team.

They’re quick: I’ve sat through some painfully long meetings in my time where the topic of conversation has been what bugs to fix next. Many of these meetings I’m sure could have been wrapped up in a fraction of the time. The good thing about a bug lucky dip is that it is quick. They skip the (often meaningless) discussions about bug priorities and move straight to the important part; what bugs are we fixing today? That’s not to say that I don’t consider the importance of one bug against another when I’m selecting cards for the lucky dip, I just don’t dwell on it. If people ever believe there is a more important bug on the board than the one they have picked, it’s not a problem; they just swap one for the other. No debate necessary.

They’re non-disruptive: Collaboration is an essential part of agile software development, but distraction and disruption are the enemy of the good. Good agile teams know they must continually review this balance by looking for opportunities to collaborate more effectively, whilst also eliminating unnecessary distractions and disruption. The good thing about a bug lucky dip is that the team has already been disrupted to attend the daily stand-up (a disruption that the majority of teams accept as essential). Staying an extra few minutes at the end of the stand-up rarely disrupts anyone’s day. It also helps streamline team collaboration as picking up an unfamiliar bug will often be followed by an offer of help at some point during the day.

They help keep the bug count low: Bug lucky dips are a mechanism for encouraging teams to keep their bug count low (an important practice that many teams forget). It’s easy to tag a bug lucky dip onto the end of every stand-up for a week and in the process knock 30-40 bugs off your backlog. It’s easy to fall into the trap of thinking that a large number of outstanding bugs is just putting off work until a later date (and everyone does that, right?), but as my recent article for The Testing Planet highlights, delaying the fixing of bugs has several negative effects of the team.

A final comment

Does this mean you only ever fix a given number of bugs each day? No. I always try to encourage a fix-them-when-you-find-them mentality when it comes to bugs, but sometimes this needs a helping hand. Running bug lucky dips is a good way of kick-starting this process or giving it a nudge when it falters.


2 Responses to “How to run a bug ‘lucky dip’ after your daily Scrum”

  1. Doesn’t this imply that ‘all bugs are equal’ ? Shouldn’t you be attacking the high priority bugs first rather than taking a lucky dip ?

    • Hi Phil,

      To clarify, it is the most important (highest priority) bugs that are removed from the board and taken to the lucky dip. When bugs are then randomly selected by the team, the element of chance only affects which of your highest priority bugs are fixed by which member of your team.

      As a side point (related to bug prioritisation), I frequently see teams wasting time prioritising (and re-prioritising) bugs in the middle of a sprint, by typically getting together in groups, or sometimes the entire team, to debate the classification of bugs. I hear conversations like; “I see bug 343 has been marked as a P4, but I think it is a P3 because…” someone else will then often reply, “No, I think it’s a P4 because…”

      For me this is a waste of the team’s time which could be avoided if they opted for a much simpler classification; does this bug need to be fixed this sprint – “yes” or “no”? If the answer is “yes” and the team’s velocity correctly represents the effort required to develop new stories AND fix bugs, then I find further bug priority discussions of little benefit.

      One caveat to this approach is when the team’s burn down chart begins to suggest that that they are unlikely to deliver the current sprint on time. If this is the case a more detailed ranking may be necessary, but then this ranking will need to be applied not only to the bugs in scope for that sprint, but to the stories too.

      When teams find themselves in this situation, the temptation is to “finish” as many stories as possible, whilst predominantly ignoring all but the most glaring bugs that need fixing. I can see why teams are tempted down this route, but personally I would rather see a team focus on fixing bugs before working on new stories. I.e. I’d rather see 10 stories completed to a high level of quality at the end of a sprint than 15 stories that all contain bugs.

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s