Skip to content
Home » Blogs » jackMilunsky's blog

Accounting for bugs the agile way - part II

March 6, 2009 by Jack Milunsky


Last weeks post struck a cord with readers and as a result I got some really good feedback. Based on the responses I decided to use this week's spot to clarify my position on some of the issues as I see them.

I believe that ...

1. Teams should do whatever they can to fix bugs that are found during the sprint in which they're found. The definition of "Done" means the feature is coded to standards, unit tested, functionally tested, documented and all known bugs are resolved during the sprint. If you postpone bugs, what seems trivial at first will mean significant build up of technical debt which you will need to pay for downstream.

2. Work required to fix bugs shouldn't count towards the teams overall story point velocity. You don't what to show an increase in velocity for buggy code.

3. Bugs should be treated just like tasks are treated on the Sprint Backlog and should be tracked on the Burndown. Bugs take time to fix and so you have to account for the hours.

4. Teams should not confuse Sprint capacity plannning with longer term Story point planning i.e. bugs should not be estimated in Story points.

So if you're fixing bugs as you find them why would you even need to consider bugs at the start of every sprint?

Well, there are a number of reasons...

1. You may only find bugs after you deploy to production. It's impossible to ensure completely defect free code even if your engineering processes are impeccable.

2. You may be a company that has legacy code and you're trying to pay down some of the "technical debt" that exists in the system.

3. You may have less stringent definitions of done and as a result you decided to postpone fixing them. I don't recommend this practice but that's just one of the realities a scrum master has to deal with.

Next week I promise to take you through a detailed account on how we do planning and how we incorporate all aspects of planning including user stories, bugs and refactoring tasks.

Bookmark/Search this post with:
  • Delicious
  • Digg
  • StumbleUpon
  • Propeller
  • Reddit
  • Technorati

About the Author: As COO and Scrum Master, Jack Milunsky heads software development at Brightspark. Jack is an early adopter of Scrum and has a great passion for early stage startups. Jack is co-creator of Agilebuddy, a next generation Scrum Application SaaS. Jack combines over 18 years of experience managing software development teams both large and small. You can follow Jack for great tips on Agile at http://twitter.com/agilebuddy

Permalink

Comments

awesome summary...

March 6, 2009 by Kevin E. Schlabach (not verified), 2 years 48 weeks ago
Comment id: 2332

very good approach...

awesome summary...

March 6, 2009 by jackMilunsky, 2 years 48 weeks ago
Comment id: 2333

Thanks Kevin,

I try my best to bring a practical viewpoint on the issues as we are actively involved in many software projects and practice scrum, XP and TDD pretty religiously. So my experience is pretty handson.

Cheers
Jack

Yes and no

March 7, 2009 by Janusz Gorycki, 2 years 48 weeks ago
Comment id: 2335

"It's impossible to ensure completely defect free code even if your engineering processes are impeccable" - I am absolutely with you on this. I have seen quite a lot of opinions to the contrary, even on this site. However, I am yet to find bug-less code in _any_ product (developed in agile way or otherwise). I think bug-less code is a delusion we should all get rid of. Claim that "our code is bug-free" is audacious beyond belief. I have an outstanding bet here (read one of my past posts on ASD) - I will buy 1 pint of beer for every minute it takes me to find bug in your product. I am yet to buy beer for anybody.

However - some of the gurus of agile methods (e.g. Mike Cohn) do advocate estimating bugs in story points just as you estimate stories. There are several reasons, one of which could be that "improvement in the code quality" may very well be a very valid goal of the project for the product owner. The problem with this though is that often times bugs can be very problematic to estimate for size, because by their very nature they represent an unknown - fixing a bug requires a discovery (debugging) phase, which is not necessarily time-bound.

In our team, we prefer assigning a chunk of the iteration (20% or so, depending on how much technical debt we currently have) to fixing as many outstanding bugs as possible

Affect on testing

March 7, 2009 by David (not verified), 2 years 48 weeks ago
Comment id: 2336

This approach also allows for more useful user testing at the end of the sprint. Bugs can cause a loss of 'flow' or affect the overall look and feel of whate the spring is delivering. This could lead to feedback not being delivered correctly and coming out in the future instead.

Regards,
David
http://www.jacksguides.com

Yes and no

March 7, 2009 by jackMilunsky, 2 years 48 weeks ago
Comment id: 2337

Thanks for your comments Janusz.

You make some very valid comments.

In regards Mike Cohn and estimating bugs in story points. Last I checked this was not his recommendation but I stand to be corrected. I actually communicated with him on this very fact. But I may have missed this. Never the less, I buy your argument about having a Sprint goal to increase quality and then estimate those stories in story point. Bottom line is if it works for you, then there's nothing wrong with that approach.

Also, I can definitely see bugs being really hard to estimate due to their very nature. In our organization though, I guess it's because we're not heavy on the research side, we find it relatively easy to esitmate how long in hours it's going to take and so we track that on our burndown.

Thanks for your feedback
Jack

Yes and no - re: Cohn

March 8, 2009 by Janusz Gorycki, 2 years 48 weeks ago
Comment id: 2338

Jack, it is very possible that either I am confusing Mike with some other bloke, or that he changed his approach lately (where "lately" means "some time after he wrote the book/article/video/whatever that I have read/seen" :)

Re: Dealing with defects/bugs and capacity planning.

March 13, 2009 by Kane Mar (not verified), 2 years 47 weeks ago
Comment id: 2361

Hi Janusz,

>In our team, we prefer assigning a chunk of the iteration (20% or so, depending on how
> much technical debt we currently have) to fixing as many outstanding bugs as possible.

That is certainly one common way of dealing with bugs. There are both advantages and disadvantages of this approach which I believe are worth discussing.

The advantage (as I see it) is that this approach fully acknowledges that defects/bugs are a priority and some time is deliberately allocated for fixing defects and improving code quality. I would argue that these are definitely good things.

The disadvantages (as I see it) is that there is a lack of transparency between the team and the Product Owner (PO). Is each team member really spending 20% of their time on fixing defects? Are they really working on the highest priority item? How do you resolve cases where new functionality is more important and fixing a defect?

My preferred approach (and this is entirely personal), is to have the team under commit as part of the planning meeting, and when the have completed the committed work they would then pull in additional work from the product backlog (which may include both new functionality and bug fixes). This approach is far more explicit because the PO knows exactly what the team is working on. It does, however, imply that defects/bugs are placed on the product backlog and prioritized along with everything else.

All the best,
Kane Mar
http://KaneMar.com | http://www.linkedin.com/in/kanemar
http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival

Pre-DONE v Post-DONE

March 15, 2009 by Mike Bria (not verified), 2 years 47 weeks ago
Comment id: 2374

I think it's important to clarify that you're treating bugs found on "current stories" and bugs found on "DONE" stuff differently.

Other words, bugs found during the iteration on stuff slated for the iteration ("current stories") are treated (from a planning/tracking P.O.V.) just like any other task involved in getting a story to DONE. Right?

On the other hand, bugs found on already DONE stuff (eg, coming in from your real users) might benefit in many cases from just being treated like other "new feature" stories. Other words, each gets its own "story" and is prioritized, planned, and tracked (as a part of velocity for instance) like all your other "stories". Also right?

As for allocating 20% of your time to fixing these types of bugs, I think that's a fair approach. That's more a function though of how you are prioritizing bugs against "new stuff" than anything else isn't it? You could still apply what I state in the previous paragraph (bugs are "storied") and follow your 20% rule to determine in any given iteration how many of those "bug stories" will make it in.

Of course, all that said, I also still work with many teams who don't get enough of this type of bug work to find it useful to be so formal about handling them. As with all things, common sense applies.

Anyway, thought I'd throw that in the ring, hope its helpful!

Cheers
MB

Bugs, Pre vs Post

March 15, 2009 by jackMilunsky, 2 years 47 weeks ago
Comment id: 2376

Hi Mike,

I like what you say. However, in my opinion I still prefer to treat bugs as you do tasks in the Sprint Backlog no matter when you find them. I prefer not to treat (as you suggest, post found) bugs as you do stories and include in the velocity. Additionally even though I treat bugs in the same way I do tasks on the sprint backlog, I still like to keep them separated. That way you can get bug fix vs found metrics and that really helps you to manage the quality side of the business.

Remember, the effect of adding bugs into a sprint is that your velocity goes down. so on average your steady state velocity should let you schedule the right number of user stories and still leave you enough hours in the sprint to handle both types of bugs (pre and post found bugs).

Great food for thought.

Thanks for the comment.

Jack
www.agilebuddy.com

RE: Pre & Post

March 18, 2009 by Mike Bria (not verified), 2 years 46 weeks ago
Comment id: 2386

I'm not sure that I agree, on a few levels.

First, to be honest, I don't really even consider "pre" bugs to really even be "bugs" at all, per se - they're just "cost of doing business" when it comes to doing development of a story during an iteration. Sure, we want to reduce imperfect stuff ever even leaving a programmer's workstation, but pushing that to "never" is simply unrealistic (that's we we do CI, etc). So, for the rest of my discussion here, when I say "bug", I'm meaning the "post-done" stuff.

So then, regarding these bugs (the "Post" stuff).

About metrics. I don't see how treating them similar to how you treat stories (in terms of prioritizing, slotting into an iteration, etc) prevents you from also keeping defect metrics about them.

About velocity. I see "velocity" as a measure only useful in allowing a team to get a sense for how much "planned stuff" they tend to get done in a given period of time. What's the difference if that "planned stuff" is a "bug" or a "feature"?

Taking this even a bit further, isn't a bug just a "feature" in sheep's clothing anyway. Both a "bug" and "feature" are requests to make the software look/work differently. Both have acceptance criteria, both require development, testing, and deployment (among other things in most cases of course). This probably is the even more fundamental reason my bugs tend to get "story stickies" instead of "task stickies" on my wall.

Hopefully I'm not coming off as argumentative here, just trying to be clear.

Cheers
MB

BTW, "not verified"?

March 18, 2009 by Mike Bria (not verified), 2 years 46 weeks ago
Comment id: 2387

So, how do I get myself "verified"?

Verified = logged in

April 8, 2009 by Artem, 2 years 43 weeks ago
Comment id: 2443

Just create an account on this site and log in. Then you'll be "verified" and no spam bot for sure.. eh, to our understanding :)

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of AgileSoftwareDevelopment.com