Dealing with Hard to Find Bugs (Sprint Killers) in Scrum

This question was asked in an online forum(I’m paraphrasing):

> How do people here handle the impact of difficult errors/bugs (but not legacy bugs) on sprint progress?  Like ones that take weeks to solve?

In my professional opinion, the answer is: we make them transparent and try to improve upon them — at Daily Scrums, Sprint Reviews, and Sprint Retrospectives.

I tend to coach teams to handle bugs in Scrum using the Bradley Bug Chart.

One of the aspects of the Bradley Bug Chart is that bugs like the one mentioned (i.e. non legacy bugs) end up on the Sprint Backlog.  Because they end up on the sprint backlog, if one is using Story points and velocity, no story points are assigned and no velocity is gained from fixing bugs.  This, once again, helps provide transparency on to the lack of progress that the team might be making due to bug fixing.  The truth can be a hard pill to swallow, but the truth will also help set you free from these mistakes in the future.

The transparency should help all involved understand that there is something that needs improving, that is dragging down the team’s ability to produce new features and working software.  I would argue that this is not a sprint killer.  It is simply a fact of complex software development.

The real issue comes down to this:  Scrum transparency is trying to tell your team something.  What is it trying to tell your team?  What is your team going to do about it?

Related Articles

• The Tao of Scrum – Transparency

• One way to Handle Bugs and Production Support in Scrum

• One way to Handle mid-Sprint Scope Changes in Scrum

ScrumCrazy.com update:

• Looking for Agile/Scrum/Kanban Coaching or Training?  Contact us for more info.  We have some good specials going on right now, but they won’t last long!
• Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc.  Feb 28th in the Denver Tech Center.  More info and sign up here!

Towards a Catalog of Scrum Patterns

I’ve been thinking a lot lately about Scrum patterns.  To that end, I’ve drafted a conceptual model, which is depicted in the below image.  (You may want to click the image twice to see a bigger view of it)

“Sprint Progress Monitor” is my term for what used to be called the “Sprint Burndown.”  In the 2011 Scrum Guide, Sprint Burndowns were no longer required but some way of monitoring sprint progress, via summing the remaining work, was still required.  In the Scrum Guide, it is made clear that these practices can be implemented using several techniques, and “techniques may vary” from team to team.  So, this is what inspired me to use the term “Scrum Technique Pattern.”  A Scrum Technique Pattern(STP for short) implements the intentional gaps left by the Scrum Guide.  Teams can inspect and adapt their technique patterns, while still fulfilling the Scrum framework.  Said another way, there are intentional “variation points” in Scrum, and the STP’s are different ways of implementing those variation points.

“Optional Scrum Patterns” are patterns that can be used in conjunction with Scrum, but are not specific implementations of Scrum techniques as specified or required in the Scrum Guide.  These can be just about anything, but they must follow and/or support Scrum principles in order to be considered as an Optional Scrum Pattern.

I also see the need for the ability to create a “mashup” of different Scrum patterns to create a set of practices and techniques for a particular team or context.  For instance, we might start out with a Scrum Starter Kit that includes things like:

• Holding a Release Planning meeting every 2-3 months (OSP)
• 2 Week Sprints (STP)
• Using Story Points to estimate Product Backlog Items(STP)
• Using Ideal Hours to estimate Sprint Backlog plan items(STP)
• Doing a typical burndown chart to sum the remaining work for the sprint(STP)
• Representing Undone Work(OSP)
• Doing the typical “round robin” style of the Daily Scrum(STP)
• Doing a fairly typical “Plus-Delta” retrospective analysis(STP)

Any of the above patterns could be interchanged with other patterns, and the Scrum implementation would still conform to doing correct Scrum.  Presumably the change to different patterns would be an attempt to improve a team’s ability to delight their customers and users.

Who writes these patterns?  Where do they come from?

In a word, anywhere.  I’ve seen dozens of them on the internet and in books.  I’ve documented a few original ones myself(though many of mine are adapted from others, and I would make every reasonable attempt to give credit where credit is due).  I would not be attempting to create all of these patterns, but to assemble them and label them so Scrum practitioners can easily understand which of them are optional, and which are fulfilling required practices of Scrum.  Of course, it will also become helpful to understand where these patterns fit into the grand scheme of Scrum, and I have some ideas along those lines, too.

I will keep iterating on this concept, and I hope to get back to you with more on this topic in the future.

My Preferred Agile, Scrum, and XP Resources

If you’re printing this post, it can be found online at: http://www.scrumcrazy.com/My+Preferred+Agile%2C+Scrum%2C+and+XP+Resources

A friend recently asked me this question:

What would you recommend in terms of the best book(s) to learn about Agile (Scrum) with XP practices? That is, if you had a team of developers who were newbies to Agile, Scrum, and XP, what books/articles would you give them to bring them up to speed on what they should be doing and how they should be doing it?

This question from my friend is a very tricky one, in that it is very broad and generic, and my friend gave me no extra team or organizational context to go on, so about all I can do is give a generic answer, and that is what I’ve done below. If you’re looking to combine Scrum with XP practices, be sure and see Kniberg’s book under “Scrum” below.

Don’t have time to read all of these? Well then, read the first couple from each category, and then continue working your way down each list.

My Preferred Resources

All are in order of my personal preference in each category.

---

Scrum

1. The Scrum Guide (Must read for all)
   • http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf
2. Deemer, et al. “The Scrum Primer”
   • http://www.scrumprimer.com/
3. Cohn’s _Agile Estimating and Planning_ (Must read for Scrum Masters)
   • http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
4. Pichler’s _Agile Product Management…_ (Must read for Product Owners)
   • http://www.amazon.com/Agile-Product-Management-Scrum-Addison-Wesley/dp/0321605780
5. Cohn’s _Succeeding With Agile…_ (Must read for Scrum Masters once they have a few Sprints under their belts)
   • http://www.amazon.com/Succeeding-Agile-Software-Development-Using/dp/0321579364
6. Kniberg’s _Scrum and XP From the Trenches_ (Note that there is a free PDF download of this book if you register with InfoQ – something I recommend anyway)
   • http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
7. Derby/Larsen’s _Agile Retrospectives_
   • http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649

---

XP (Extreme Programming)

1. Jeffries’ “What is Extreme Programming?”
   • http://xprogramming.com/book/whatisxp/
2. Jeffries’ _Extreme Programming Installed_
   • http://www.amazon.com/Extreme-Programming-Installed-Ron-Jeffries/dp/0201708426
3. Koskela’s _Test Driven…_
   • http://www.amazon.com/Test-Driven-Acceptance-Java-Developers/dp/1932394850
4. Martin’s _Clean Code_
   • http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
5. Feathers’ _Working Effectively With Legacy Code_
   • http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
6. “The Rules of Extreme Programming”
   • http://www.extremeprogramming.org/rules.html
7. Wiki entry on XP Practices
   • http://en.wikipedia.org/wiki/Extreme_programming_practices

---

Agile/XP Testing

1. Summary of Lisa Crispin’s Presentation to Agile Denver on Test Automation
   • http://properosolutions.com/2011/10/the-secrets-of-successful-test-automation/
2. Cripin’s “Using the Agile Testing Quadrants”
   • http://lisacrispin.com/wordpress/2011/11/08/using-the-agile-testing-quadrants/
3. Crispin/Gregory’s _Agile Testing_
   • http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468
4. Crispin/House’s _Testing Extreme Programming_
   • http://www.amazon.com/Testing-Extreme-Programming-Lisa-Crispin/dp/0321113551
5. Cohn’s “The Forgotten Layer of the Test Automation Pyramid”
   • http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
6. Osherove’s _The Art of Unit Testing_
   • http://www.amazon.com/The-Art-Unit-Testing-Examples/dp/1933988274

---

User Stories (which originated in XP)

1. My “User Story Basics” article and all of the links at the bottom of that article
   • http://www.scrumcrazy.com/User+Story+Basics
2. Cohn’s _User Stories Applied_
   • http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685
3. Cohn’s _Agile Estimating and Planning…_ (Chapter 12: Splitting User Stories)
   • http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
4. Lawrence’s “Patterns for Splitting User Stories”
   • http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/

---

Special Agile Topics (if applicable)

1. Deemer’s “The Distributed Scrum Primer” (If some of all your team is remotely distributed)
   • http://www.goodagile.com/distributedscrumprimer/
2. My article entitled “The Role of Managers In Scrum” and all of the links at the bottom of that article
   • http://www.scrumcrazy.com/The+role+of+Managers+in+Scrum
3. Larman/Vodde’s _Scaling Lean Agile…_ (If your Agile transformation involves a very large organization)
   • http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961

User Story Basics – What is a User Story?

What is a User Story? I’m glad you asked!

First of all, it’s important to say that User Stories are not a part of Scrum as defined in the required practices in the Scrum Guide. User Stories are but one way to represent Product Backlog Items in Scrum, and while it is the most popular method used, it is not the only method. Still, though, I would like to remind you that the User Stories practice is totally independent of Scrum, and thus it is not defined by Scrum. As such, everything else in this post is about the User Story practice and not Scrum itself.

Beware the common misconception!

There is a common misconception in the industry that a User Story is a sentence like:

• As a <user> I want <some functionality> so that <some benefit is realized>.

THIS IS NOT A USER STORY!!! This is the biggest User Story trap in existence! See Trap#1 and #8 of my article on User Story Traps.

What is a User Story?

<Definition>
A user story describes functionality of a system that will be valuable to a Non Development Team(NDT) stakeholder of a system or software. User stories are composed of three aspects:

• a written description or short title of the story used as a token for planning and as a reminder to have conversations
• conversations about the story that serve to flesh out the details of the story
• acceptance tests that convey and document details and that can be used to determine when a story is complete

</Definition>

What do they mean by Acceptance Tests?

Typically, in the context of a User Story definition, we mean tests that are represented by conversations, textual descriptions, tables, diagrams, automated tests, and so forth. When these Acceptance Tests are applied to the completed, implemented User Story, all of the tests should pass, and will thus prove that the story has been implemented correctly. If some functionality was not covered in a User Story acceptance test, then it wasn’t a requirement for that particular User Story.

Technically, in the context of a User Story definition, an acceptance test need not be automated or implemented. At the minimum, it should be described conceptually. The test should then be executed in order to prove the story and get acceptance, whether that be a manual or automated process. If your conceptual acceptance tests are described by one or more automated tests, then that is generally a much better practice, but not absolutely required.

Acceptance Tests should be automatable about 90+% of the time, though again, it is not required that they be automated. Having said all of that, when teams strive for development speed and quality, very few get far along that road without automating a large portion of their acceptance tests.

Acceptance Tests, in the context of User Stories, are also sometimes called Story Tests, Acceptance Criteria, Conditions of Satisfaction, and Test Confirmations.

Ron Jeffries, one of the co-inventors of User Stories and Extreme Programming (where the User Story practice comes from), has a good article that also describes User Stories in a basic way.

When do these Conversations and Acceptance Tests get created?

Typically, this happens in weekly Product Backlog grooming(also known as a Story Writing Workshop, Story Grooming, etc) sessions, but can also happen informally. The most effective backlog grooming includes some stakeholder/user representatives, the entire development team, and a Product Owner (Scrum) or Customer(XP). These sessions happen weekly and usually last 1-2 hours each. The goal of the sessions is to get stories that are “ready”, meaning the team has a shared understanding of the Acceptance Tests, and has the vast majority of the information they need to implement(code) the feature. See What does Product Backlog Grooming Look Like? for more on that topic. Keep in mind that sometimes a single User Story will be discussed in 2-3 grooming sessions before it is “ready”, especially if there are open questions or complex logic involved.

Frequently Asked Questions

Should I use a User Story to represent bugs/defects in a system?
The short answer is “it depends.” If it is a legacy or deferred bug, then yes, and it should end up on the Product Backlog(story points assigned). If it is a bug that was introduced since Scrum/Agile was put in place, then no, and it should end up on the Sprint Backlog(no story points assigned). See One way to handle Bugs and Production Support in Scrum for the longer answer.

Where do I get more info?

• A User Story Checklist
• User Story Basics – The Longer Story
• To see what User Story Traps cause a lot of pain on teams, see User Story Traps
• To see how to make sure your stories are “ready” for implementation, check out The Definition of Ready
• To see more info on creating Acceptance Tests, see my Presentation – Story Testing Patterns
• To see how well your team is implementing the User Story practice, see the The Bradley User Story Maturity Model
• Ron Jeffries’ article: Essential XP: Card, Conversation, Confirmation
• The best book on the subject of User Stories, IMO, is Mike Cohn’s User Stories Applied.

What’s a good way to establish a Story Point Scale?

Here is what I generally coach:
(I assume that you have the pseudo fibonacci numbers that come with standard story point cards:  1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100)
1.  Try to imagine the smallest actual story (something that provides user/stakeholder value — an actual tiny feature).  Sometimes that could be just a configuration change, or  small change in the GUI.  Either give that a single point or a 1/2 point.  That’s your lower bound.
2.  Now, to be able to properly indicate a rough upper bound, I tell teams this upper bound will be the rough equivalent of the maximum story size — that is, the biggest story that a developer (or pair if you’re always pair programming) could do on her own in one iteration.  I usually tell teams to pick 8, 13, or 20 for the upper bound number so that we leave a few numbers that can be used for Release Planning and epics (= story too big to fit into a sprint).
3.  You now have a range starting with .5 or 1, and ending with something like 13.
4.  Look at a bunch of stories in the upcoming backlog, and size them in your range, remembering the smallest lower bound story you could imagine, and the upper bound story that could be finished(totally done) in one iteration.
This Agile estimation technique documented by Brad Swanson might help:  http://properosolutions.com/wp-content/uploads/2010/05/agile_estimation_2.0-for-pdf.pdf
5.  From here on out, size all stories relative to the first stories you sized as well as your upper and lower bound.
6.  Do this for 3 iterations, then retrospect and decide if you need to adjust your scales somehow.  Adjust only if the team feels a big need to.  Just be sure, if you do adjust your scale, to do so for ALL of the stories that you have previously sized(those that were in previous iterations, as well as the entire backlog that has already been sized).   If the team chooses to do this adjustment, it is only done once, and never again.  Sometimes teams new to Story Points want to spend too much time estimating.  In those cases, I’ve found that it helps settle the team’s nerves when they know they’ll have the opportunity to do this one time adjustment after the 3rd iteration.
7.  Go forth and prosper!

© 2010, 2011 Charles Bradley.  All Rights Reserved.

About the author:Mr Bradley is an experienced Scrum Coach, Certified ScrumMaster, and Certified Professional ScrumMaster I.  In addition to his Scrum credentials, Mr. Bradley is also a highly capable, full lifecycle experienced, software development team lead that prefers XP for good engineering practices.   He is Sun Certified in Java, and has  13 years of experience in J2EE application development across all tiers.  More recently he has also picked up some good C# experience as well.  In his spare time, he enjoys driving his wife crazy by talking about Scrum, especially when he refers to his “honey do” list as his “personal backlog” and asks his wife to prioritize her requests.  He lives in Denver, Colorado, and he is easily found on LinkedIn.

In Scrum, Should I assign Story points to bugs?

This post has been deprecated.

Essentially, if you look at the Bradley Bug Chart on the replacement post, any bug that ends up on the Product Backlog(Legacy Bug, “Not a Bug”, “New Feature”, or “Deferred Bug”, etc), should be assigned story points, and any bug that ends up on the Sprint Backlog should not be assigned story points.

[old deprecated article below –V]

First a definition.

Bug – Any behavior of the system that either violates an acceptance test, or is unacceptable system behavior that cannot practically be covered by an acceptance test(for example, aesthetics issues, or legacy bugs).  Another way of saying this is any behavior that is inconsistent with previously well understood requirements and/or acceptance tests.

This definition is useful when deciding whether something is a bug or an enhancement.

So, I break bugs down into the following three categories and assign points as follows:

1) Legacy bugs
I define a “legacy bug” as any bug that was introduced prior to the team adopting Scrum. Those go on the backlog as user stories and are estimated in points and prioritized by the PO.

2) Scrum Era bugs
Any other “bug”, introduced since adopting Scrum, is fixed within one sprint of it’s discovery(this sprint or next) and no story points assigned, unless both the PO and dev team agree to defer the bug beyond that next sprint(Deferred bugs). If either the dev team or PO chose to have the bug fixed this sprint or next, then the bug appears as a task for the sprint, and is estimated in hours.

3) Deferred bugs
These go on the backlog and are estimated in Story Points and prioritized by the PO.

While this logic is somewhat complex, all other decent solutions to the “should I assign story points to bug fixes” are also fairly complex, and usually have much larger risks of bad effects.

Some subscribe to this theory that  “bugs can’t be well estimated” theory. I don’t.  Here’s why.

1. I encourage team members to take some time to investigate a bug, up to an hour to estimate a bug that appears to be nasty. This helps reduce estimation inaccuracies.
2. I encourage teams to then “inspect and adapt” on sizing bugs, just as they would for User Stories.
3. If the team still can’t be terribly accurate after a few iterations, then I would probably just encourage them to spend more time investigating nasty bugs to obtain a better estimate — this would be an extreme situation in my opinion(very low quality product). Note that they can only investigate for an estimate, the time is not meant to spend diagnosing or fixing the bug.

Some teams try to set aside a set amount of time each sprint for fixing bugs, and assign story points to that effort.  I also don’t agree with that, as I feel it hinders transparency and makes it too easy for teams to sweep new bugs under the rug. “We’ll have time to fix this later in the bug fixing sprint or in the bug fixing time-box next sprint.”

Having said all of the above, while PO’s are certainly allowed to prioritize bugs into sprints, the dev team is also allowed to pick any bug it feels needs fixing (whether it be on the backlog or not), and bring that into the sprint as a task (they gain no story/velocity points for this, regardless of whether the bug was on the backlog or not). Only the dev team can decide how much product backlog to bring into a sprint, so if they decide to spend ~ 50% of their sprint bug fixing things not prioritized by the PO, so be it, but it will be visible because their velocity will be lower.

So, in short, Legacy and Deferred bugs can be fixed either:
a) When they are prioritized into the sprint because the PO perceives business value gained (story points added into velocity), OR
b) When they are brought into a sprint by the dev team because the dev team perceives value, and no story points are added into velocity as a result of fixing these bugs.

According to Mike Cohn’s User Stories Applied :
“…the developers will estimate how much work they’ll be able to do per iteration. We call this velocity…”

Further if you measure velocity in User Story Points, then each User Story must be
“…valuable to either a user or purchaser of a system” (also from Cohn’s book)

So, velocity is meant to be an estimate of a team’s iteration capacity to deliver User Stories that are of value to users and stakeholders outside of the dev team. I believe the above strategies that I describe do just that.

I could be wrong though, and I encourage others to let me know if they think I am!

© 2010, 2011 Charles Bradley.  All Rights Reserved.

About the author:Mr Bradley is an experienced Scrum Coach, Certified ScrumMaster, and Certified Professional ScrumMaster I.  In addition to his Scrum credentials, Mr. Bradley is also a highly capable, full lifecycle experienced, software development team lead that prefers XP for good engineering practices.   He is Sun Certified in Java, and has  13 years of experience in J2EE application development across all tiers.  More recently he has also picked up some good C# experience as well.  In his spare time, he enjoys driving his wife crazy by talking about Scrum, especially when he refers to his “honey do” list as his “personal backlog” and asks his wife to prioritize her requests.  He lives in Denver, Colorado, and he is easily found on LinkedIn.