The Sprint can have 10% buffer reserved to bugs?

I'd like to know if this 10% reserved to bugs are acceptable for Scrum or if we do that, we are not using scrum?

Do those bugs and their resolution constitute waste, and could they be mitigated by improving the Definition of Done?

That depends on the scenario. I mean, as they are bugs we can't predict them.

There are a lot of minor bugs that I can escalate to next sprints but the problem is when we have a blocker in production.

What happens... I have the PO worried to finish this bug sooner than achieving the sprint goal accorded in planning.

In my point of view, we'll be deviating from Scrum. Aren't we?

Could the Sprint Goal not be something related to improving your Time to Market or Ability to Innovate?

This could be realized by the resolution of bugs, technical debt, or other PBI's. 

Questions asked by Ian are very important. If you deal with a production blocker - this is really serious and should not happen frequently (or at all if possible), hence booking time for solving such issues indicates a problem. From my point of view the most important thing would be to dive into the source of each production blocker and find a way to learn from that experience e.g. by changing the DoD, DoR, fixing pipelines or whatever is the cause :) 

I echo the questions and suggestions mentioned above and will take a slightly different route. 

I would suggest the teams plan for far less than 90% of their capacity, closer to 50-60%. As we all know, things come up and while sometimes they are avoidable, there are things that just happen. Because of that, the teams need time to adapt. Your sprints are 2 weeks, so 10 business days, even if you say "let's just plan for having 9 days to work on our product", you're likely to come up short. Between the Planning, Review, and Retro, you're already at a day and a half of time devoted to those events. Add up the cumulated daily scrum time and that clears the remaining half day so you can expect to have 2 of the 10 available days devoted to events and collaboration. Now, what happens if a team member gets sick and they are gone for a day or 2? What about major blockers that would cause the team to go "pencils down" and resolve it together? 

I was always taught that it is better to under-promise and over-deliver than to over-promise and under-deliver. Teams that don't want to plan for a fraction of their capacity use the excuse of "well we can't just sit doing nothing at the end of the sprint when we complete the increment early." My reply is typically "you're right, and you don't have to worry about that because there is ALWAYS work to be done. Pull in a new item from the backlog, pull in some lingering technical debt or defects, or whatever can be done to deliver value." 

Lastly, remember that items in Progress at the end of the sprint mean nothing, the "Done" increment is what counts.

Good teams are good at managing and fixing defects, production hickups etc. as fast as possible. It's not a bad thing to know that whatever happens, 9 out of 10 sprints you can fix any and all disturbances in max. 10% of your time.

Great teams, however, are good at finding ways to not have disturbances in the first place. They constantly inspect what holds them back from maximizing value and quality, reaching sprint goals, deliver stable releasable trustworthy increments etc., and then adapting their ways to measurably avoid disturbances in the future.

Easy to say, very very hard to do. But we're not in this because it's easy, are we? :)

I'd like to know if this 10% reserved to bugs are acceptable for Scrum or if we do that, we are not using scrum?

The goal of Scrum is to produce a release-quality product at the end of each iteration, and to promote an empirical mindset where frequent inspection and adaptation take place.

That said, does this PO request to allocate 10% of the Development Team's capacity for production support impact any of the above objectives?   Couldn't this be tried out as an "experiment" over a few sprints, and inspected by the PO and Development Team afterwards to determine if it helped to improve how the Scrum team worked and delivered value?

Hi guys, first of all, thanks for your comments!

My team is in a delicated position,  we are like...

- Team was created in 2018

- We are working in 3 projects:

• Project 1: It was delivered in 2017 (before my team be created) and this is from where the bugs appears;
• Project 2: The project that my team was created to work in the first place (later we covered project 1 and 3);
• Project 3: New project

The bugs are from a project that we didn't help to deliver the product, but as we are responsible for all LATAM projects, we "inherited this bomb".

- And in short words, we are responsible to do a refinement and connect product X to 4 other products. (Product 1 can be sold separated but the other 4 products can only be sold with this math). The product is too much internal from the company, so technical details won't help here.

- So what I have? 

• 5 product owners to handle;
• An old project with bad quality;
• Normal projects

Here is some example of where my team is:

Product X -> My Team -> Product 1, 2, 3 and 4.

Follows some comments about the questions:

- Do those bugs and their resolution constitute waste, and could they be mitigated by improving the Definition of Done?

Not in this case, as mentioned above the bugs are coming not from my team but from an old project that we need to support.

- Could the Sprint Goal not be something related to improving your Time to Market or Ability to Innovate?

Thank you Ian, a good idea came to me. We can have a "Test/Fix sprint" using problematic data and trying to clean this data. I know that we'll deviate from scrum from one sprint, but in long term I'll be able to shield my team better.

- I was always taught that it is better to under-promise and over-deliver than to over-promise and under-deliver 

Thats true Curtis, but if we do something like this, won't we be more "Kanban" than "Scrum"?

- Couldn't this be tried out as an "experiment" over a few sprints, and inspected by the PO and Development Team afterwards to determine if it helped to improve how the Scrum team worked and delivered value?

Sure, we can try it. But my main concern is like: If we do this way, won't we be more "Kanban" than "Scrum"?

That's a very clear description. Nice!

Firstly: if you have one Scrum team that is responsible for 4 or 5 separate products under 5 separate product owners, you have a serious structural challenge. I imagine you keep 4 or 5 separate backlogs as well. How do your team and product owners order items? How do your Sprint Planning meetings work? How do you select items from many Product Backlogs into one single Sprint Backlog?

Is a situation thinkable where your organization combines this into one product vision with one product owner? I don't care if it's 5 different codebases under the hood, the point is to have a single Product Backlog, and a single Product Owner who orders it and maximizes the value that your team delivers.

If you're afraid of "drifting away" from Scrum, I would start focusing on changing that situation :) The rest is second.

About the drifting from Scrum to Kanban: why would that be a problem? If Kanban is a better solution for your environment than Scrum, by all means, switch. Instead of choosing a framework, focus on empiricism and let it help you discover what is right for your team and your (single) product.

João - I don't quite understand what your team is working on. You mention both Projects and Products.

Do you have 5 products and 3 projects? Or just 5 products? Or 1 product?

If you are supporting a project that finished in 2017, which product is this related to? If the project ended it is no longer a project.

I think the experiment over a few sprints of improving the product may help as was suggested. I don't see this as deviating from Scrum - it's just a different priority for the work your team is doing.

Thats true Curtis, but if we do something like this, won't we be more "Kanban" than "Scrum"?

Why do you feel it would be more Kanban by finishing the Sprint Goal early and the team goes back to the backlog to pick up additional work? If the team produces a "Done" increment by the end of the Sprint, there is nothing that says they cannot add in technical debt or defects or anything in addition to that.