We have been using Scrum methodology and have been mostly successful, but there are few weeks where the sprints are totally crashed by customer demands or defects.

Is there a better way of handling the product road-map and to respond to the customer? Would you suggest splitting the group to deal the issues separately, or do you suggest splitting all the developers' time to give them a buffer (perhaps 20%)?

Goals: To end crashed sprints and remain as responsive as possible to the customer.

  • 1
    How long are your sprints? How much time, per sprint, are you using to fix bugs? Do you have testing harnesses in place? And, do you have a fast track process in place?
    – Josh Bruce
    Mar 22, 2013 at 23:12
  • 1
    Oh, and how large is your current team - less the PO and SM?
    – Josh Bruce
    Mar 23, 2013 at 0:36
  • @SharpArrow, Welcome to PMSE! I've taken a stab at editing the title to focus on your goals. Let me know if I missed the mark. Mar 24, 2013 at 15:18
  • @JoshBruce: Our Sprints are 1 week long. My team is 7 dev. We do have test automation. Can you please clarify which fast track process are you referring to ?
    – SharpArrow
    Mar 25, 2013 at 20:58
  • @SharpArrow: See my answer regarding fast-track, and some other concerns. Two concerns I would have based on your response, would be maybe the team is taking on too much and, without bring on 2 or 3 more team members, the resulting "split" teams might not have a desirable level of knowledge diversity.
    – Josh Bruce
    Mar 25, 2013 at 22:33

5 Answers 5


Defects are signals. Something is going on, which needs to be changed. Most probably you have some quality issues, and it is urgent to handle them as soon as possible.

On the other hand, I suggest to talk to the Product Owner. She should be able to prioritise the user stories and bugs (you can handle bugs as user stories, but they don't hold any value).

Having 20% for bug fixes won't really solve the problem. If you have more bugs you can fix in 20%, you'll have 30%, than 40%. Eventually, there will be colleagues who'll only fix bugs.

Try to add a [tech] user story which fixes the root cause of the bugs. This is the agile approach. But it is crucial to coordinate with your Product Owner.

  • Thank you for the response. Are you saying that we have a generic user story for every week/sprint that says. As a developer, I want resolve the root cause of the bugs. As the consumer defects/demands comes in we write requirements for those under this story and prioritize ?
    – SharpArrow
    Mar 25, 2013 at 21:12
  • Finding the root cause shouldn't be a user story, because it is part of the quality process, but its result can be one. For example, you figure out that certain users cannot log into your site, because of you have a character conversion problem when you store their login names. In this case the US may look like this: the database layer should store the login names as they are provided regardless the encoding the users are using. Or something similar. This US can be prioritised by the PO.
    – Zsolt
    Mar 25, 2013 at 23:21
  • I want to upvote this, but can't agree that bug stories have no value. The stories should still have points to reflect the level of effort involved, and be accounted for in velocity calculations because they affect team capacity. The stories also hold value for the users, who would certainly value working software over non-working software. Process inefficiencies need to be captured elsewhere, rather than treating certain user stories as point-free chores.
    – Todd A. Jacobs
    Mar 27, 2013 at 5:32
  • At the moment, I consider fixing bugs as a response to failure demand (something we have to do, because we do something with is not effective), and if I add a value to something which should have been there at the first place, I hide it. It must be visible and painful in a good way: need to be fixed without a reward. Like guarantee. It is a working theory that helped me a lot until know.
    – Zsolt
    Mar 27, 2013 at 12:11

I would not suggest splitting the group because of extra demands. Only if the group is too big, and there are communication issues.

Then, what you could do is except a part of the sprint to be dedicated to extra requests. One thing I found to work, is estimating as if the team would dedicate 100% of the time, and then when urgent requests come up, removing one of the User Stories from the Sprint backlog (one that has not been started), so the team would not have "extra" things to complete because of external factors.

Another important thing is, of course, try to have less defects (by doing some QA before releasing features) and, if there are new requests that are not urgent, delaying to the following sprint.


A bug is simply another word for a change request, which is the same as a feature request, which is the same as a PBI which are all proxies for things that the customer values.

Your backlog is a list of things that the customer values. Your Product Owner should prioritize it based on what the customer values most.

What ZSolt said is exactly right, an excessive defect rate is a smell and needs to be addressed as soon as possible. Piling buggy code on top of buggy code is a good way to tank your entire project.

Also, if you're running 1 week iterations, what value is there in cancelling a Sprint? How far into the Sprint are you when you realize that it needs to be cancelled? Seems a bit strange to nuke a 1 week iteration.

Edit: Bugs = change/feature/user story/otherthing

While I think it is important to have different types of work items for reporting purposes (although with an eye towards the minimalist side of the house), I treat the backlog as the difference between how the product is currently and how the stakeholders want to the product to be in the future. Therefore, anytime that you are going to alter your product, the backlog should reflect this. This allows you to prioritize bug fixes, new user stories, architecture improvements, refactoring and whatever else you do to your product against each other. I find this to be a much more transparent process.

  • Bug report as change/feature request. Could you expand on this notion for me?
    – Josh Bruce
    Mar 25, 2013 at 22:34
  • Absolutely agree. Either bugs get added to the Product Backlog and prioritized for a future sprint, or the need is so urgent that the current sprint needs an abnormal termination. Either way makes the underlying process issue more visible to the project.
    – Todd A. Jacobs
    Mar 27, 2013 at 4:57


All your problems likely stem from communication problems and a general failure to adhere to the change-control processes built into Scrum. Fix the communications issues, leverage the Scrum framework, and make any problems with the current process visible to the organization.

The Project's Problem

The project's problem is that you have both a quality-control issue and a change-control process issue. Your quality issue appears to be caused by failing to engage the customer throughout the development and QA cycles, and then treating their (presumably reasonable) bug reports as rush jobs rather than requiring the Product Owner to prioritize the change requests on the main Scrum artifact: the Product Backlog.

The Team's Problems

The Scrum Team's problems seem to include:

  1. A Scrum Master who is not working the process or educating the Product Owner or customer on appropriate inspect-and-adapt points within your iterative development process.
  2. A Product Owner who is not taking responsibility for the "definition of done" or refusing to prioritize infrastructure or training stories, story spikes, or other essentials within the Product Backlog. The Product Owner also seems to be doing a poor job setting customer expectations, gathering their requirements accurately, or engaging them after each iteration to (re)build the Product Backlog as needed.
  3. A Development Team that is over-committing by accepting stories into sprints even when they exceed the team's actual capacity. I'd bet money that the team is also not addressing quality issues or fundamental process problems in daily stand-ups or during the Sprint Retrospectives.

Abnormal Terminations

Abnormal terminations due to urgent changes in business requirements are allowed in Scrum. The Product Owner has the power to terminate the sprint at any time; the Scrum Master has the power to ensure that the Sprint Backlog is not changed during a sprint unless the Product Owner terminates the sprint and returns the entire team to Sprint Planning.

This creates process overhead, and a cost to the organization. That's necessary to ensure that the underlying process problems are addressed, rather than ignored or continually swept under the rug.

The way you are handling things now costs the business time and money. The only thing that would change by following the tenets of the framework is that it would become obvious what the source of the process issues are, because the team (and senior management) will be forced to inspect the process.


I will try to address the general concepts then, in the conclusion, address things more specific to your situation. Let me start by saying, Scrum is very flexible; however, the parts the must be there, must be there. So, some of these ideas are not part of the Scrum framework as described by the Scrum guide.

Tests Exist - Bugs Still Get Released

If you have automated testing, and the assumed continuous integration processes, in place, but bugs are still getting into releases, it seems like either the tests are incomplete (testing only the happy path) or hey are simply testing the wrong things. Try to account for more time per ticket item (not sure if you are using stories, epics, etc.); whether you are using story points or time doesn't really matter, try to increase either or both to afford your team the opportunity to create more robust/proper tests.

You may also consider examining the test writing process itself.

Diversity of Knowledge & Two Teams

The Scrum has a general recommendation of 3-to-9 people (6 +/-3), to ensure a certain diversity of knowledge and background among team members. Those with testing backgrounds, those with back-end backgrounds, marketing, design, etc. If you can bring on more people to facilitate the creation of two teams, you may consider something described in the book, Leading Lean Software Development by the Poppendiecks; the team becoming support.

The basic principle here is Team A works on a bunch of new functionality. For Scrum, the Product Owner accepts the deliverable during the Sprint Review. Team A now becomes support for the release, taking all the calls, updating all the materials, and fixing defects. Meanwhile Team B, during the same period, is continuously integrating the work of Team A into the work they are doing on new features. Now, if there are too many bugs for Team A to handle alone, then the PO may want to abandon the sprint for Team B so they can join Team A in correcting defects (this is a serious sign there is something wrong in the testing and/or review process).

The Fast Track, Level of Commitment, and Nice-to-Haves

When bugs come in, this an interruption to new feature development; however, it does happen. Take a look at the history of your sprints, how much time was spent dealing with defect interruptions (correcting technical debt)? Then, during the next sprint planning meeting, try to account for this in your estimates. Basically, determine the level of commitment the team is willing to take on for the sprint. While we would like to say 100% all the time, reality does not really concern itself with what we want. So, if 50% of the team's time in the last couple of sprints has been spent on overcoming technical debt, don't take on so much in the following sprint; instead, maybe take a different approach to the sprint planning meeting.

First, let everyone know that the team thinks they are capable of dedicating 50% of their time to new functionality; just in case. But, what you would like to do is create a first pass sprint backlog assuming 100% dedication is possible. Then, you, the team, and the PO can determine which, among those items is absolutely, positively, bar-none gonna be done in this sprint - based on a 50% commitment.

By doing it this way, you allow for what is commonly referred to as a fast track. Basically, a defect is reported. All work stops on the other tickets until the bug is fixed - it "fast tracks" passed all the other work (but you should still write tests for it to try to curtail regression). Now, since we know which items don't necessarily need to be done by the end of the sprint - those marked as nice-to-have - as long as the team doesn't get bombarded by defects over the 50% time they truly committed to - the PO shouldn't have to abandon the sprint.

Eventually, you should be able to overcome the technical debts currently in the system and, hopefully, reduce the amount of technical debt in the system; thereby, increasing the level of commitment the team is comfortable taking on per sprint.

In conclusion, if your automated tests aren't covering the defects making into the wild - the process of their creation and what exactly they are covering should probably be reviewed. Given your team size is 7, to maintain a diversity of knowledge, you probably shouldn't split the teams. The "buffer" is a good idea; however, should not be allowed to become a crutch - the team shouldn't be spending a lot of time fixing bugs, because the technical debt shouldn't be getting out there - try to figure out why it is happening. The last thing I will mention, and this is something you should consider honestly, is does your team take on too much in a sprint for 7 days? It is not meant to be a criticism of the capabilities of the team; however, given the continuous improvement nature of Scrum, maybe the definition of done has increased in its sophistication while your complexity estimates have not adjust to accommodate, for example.

Hope that helps, and answers the question. If you would like clarification or expansion on any of the ideas, please feel free to comment.

  • I agree with a lot of what you said, but feel that building a process around task-switching and 100% capacity targets does not protect the integrity of the sprint or the Sprint Goal.
    – Todd A. Jacobs
    Mar 27, 2013 at 5:03
  • @CodeGnome - That's part of the beauty of agile, we don't need to agree on everything. :) However, your points of contention (task-switching and 100%) make me think I did not communicate things clearly. Could you expand on what you are referring to so I could possibly improve and clarify my answer in that regard?
    – Josh Bruce
    Mar 27, 2013 at 7:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.