1

We are looking into a zero bug policy, but I wondered how best to represent this in sprint planning.

Should we be planning some 'empty' story points to cover this work? Does anyone else do this? If so how does it work for you?

Mand
  • 81
  • 7
  • 3
    What does that even mean? If you can produce non-trivial and truly bug-free software, you will revolutionize the software development industry and make a gazillion dollars. That's probably not going to happen. So, what's the actual team or management goal here, how are you implementing it, and how's that working out for you so far? – Todd A. Jacobs Nov 16 '17 at 20:20
  • 1
    @CodeGnome To the best of my knowledge, a 'zero bug policy' just means that bugs are given the highest priority, so the software is never shipped with any known bugs. If there's a bug discovered which cannot be reproduced except for someone living in New Zealand running a VPN routed through Hawaii at 2:30 am on Feb 29th, then you need to fix it. – Sarov Nov 16 '17 at 21:44
  • 1
    @Sarov Understood. My point, perhaps not as well stated as it should have been, is that producing software that is bug-free is not the same thing as prioritizing resources to remediate bugs. This is fundamentally a DoD and working-agreement issue, and everyone has to agree on whatever it means to that team in that organization. – Todd A. Jacobs Nov 16 '17 at 23:10
  • Just to give a short answer after reading all the answers below, that are very good : The "zero bug policy" should be added as quality goals in the DoD (Definition of Done) – DesignerAnalyst Nov 17 '17 at 07:21

2 Answers2

5

Focus on your Definition of Done and work to it. The key to Zero-Bugs is not in a wicked triage and fix process, the key is to not introducing them in the first place.

This starts with having a good definition of done, which includes all the technical steps to ensure the best code quality. For example, code reviews, automated tests, writing tests first and so on.

Then look at this post for the difference between a defect and "not done yet". A story isn't done until all tasks are complete, including tasks found while creating the story.

To get to a "bug zero goal" (which as CodeGnome points out, is a goal, not a reality) you then need to start looking into Continuous Integration/ Delivery. The shorter the time from code complete to deployed, the faster you can get feedback to fix things.

As for how to estimate/ account for it. Don't leave empty points. Instead, recognize that as you move into using a formal DoD you will probably need to spend more time on stories. So if you think something is a 5, maybe make it an 8 to represent the additional work to truly get it done. As you get better, you're estimates will get better as well.

Joel Bancroft-Connors
  • 12,543
  • 25
  • 55
  • 1
    Or keep estimating as before and accept that your velocity will slow as the story points get "heavier". I'd say it's a matter of taste but you're probably more accurate if you continue to estimate as before than if you try bake the impact of your more strict DoD into your new estimates. – Kempeth Nov 17 '17 at 08:52
2

TL;DR

Scrum certainly supports workflows that prioritize bug-fixing, but to be "Scrum" you must still adhere to the framework, especially as it relates to scope management and time boxing. Leverage the Definition of Done, rigorously inspect-and-adapt your estimation process, and add necessary items to the Product Backlog to cover development of a defect-reducing delivery pipeline to the project.

Who Doesn't Love Lists?

Should we be planning some 'empty' story points to cover this work? Does anyone else do this? If so how does it work for you?

While some teams do in fact leave spare capacity for unplanned work, this is not terribly Scrum-like. Instead, teams generally:

  1. Add "zero bugs" to the project glossary. Define it however you like, but ensure that everyone on the project and within the organization agrees on what that really means to your company.
  2. Ensure that QA, UAT, regression testing, and other quality processes are baked into the Definition of Done (DoD). No work can be counted as "done" without meeting the quality goals of the DoD.
  3. Automate testing. Better yet, incorporate test-first practices into your CI/CD tool chain to ensure that no known bugs are deliberately shipped.
  4. Respect the time box. Any work that's incomplete at the end of the Sprint, including work with known defects or stories that haven't been fully tested per the DoD yet, must be placed back onto the Product Backlog, re-prioritized, and replanned in a following iteration. Work is never blindly carried forward, but the Product Owner can keep backlog items related to bugs at the top of the Product Backlog until they're resolved. NB: This ensures that the cost of bugs and the trade-offs in capacity for bug management vs. feature development are fully visible to everyone involved.
  5. Inspect-and-adapt the estimation process. Ensure that you are including the level of effort to get to "zero known bugs" in your Sprint Planning. You may over- or underestimate this level of effort, especially at first, but 80% accuracy of your Sprint forecasts is generally a reasonable expectation of a mature Scrum Team even with a rigorous Definition of Done.

While the list above won't guarantee that you have no bugs, it does provide a reasonable framework within Scrum to implement your zero-bug policies. The rest is up to your policies, processes, and controls.

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177