What team(s) for such values

Hey Dolevo - it's very common (probably most of us experienced this scenario).

Please check this. Print in several copies and discuss with the teams. Adapt as necessary.

Hi Dolevo,

the tricky thing about Scrum is that it only makes your problems visible. It doesn't make them go away on their own. In your case, the issue are defects which are so severe that their fixes take priority over the Sprint Goal. That issue is visible now. Now what do you do?

The most important part is discovering the root cause: Why do you have defects of such severity in your product? Once you have identified the root cause, find a way to fix that by changing the way you work.

If you discover that fixing the root cause will take time or that the problem will persist for some time after the root cause has been fixed (which is likely when dealing with defects), then find a way to handle the problem in the mean time.

The chart Eugene linked to displays a process which is commonly used by Scrum teams (or similar processes at least) and may be a good starting point.

Just remember: Don't just find a way to live with your issues, but attack them by eliminating the root cause. Only that will make your team improve.

All of that being said, defects in production, even severe ones, cannot be completely avoided, so having a process in place to deal with them (like the one Eugene pointed you to) is generally a good idea. Just make sure to retrospect on such occurences to minimise them.

there are hotfix issues coming and not all goals in the sprint will be fulfilled

Can you clarify how many Sprint Goals you actually hope to achieve during the Sprint?

Hi Dolevo,

I think Julian is right. It's important to understand why this defect occorred and fix the root cause.

However, you already has the issue, so you have to handle it asap.

When you have an urgent item that comes in mid-sprint and it can not wait the next one, you have first to talk with the Development Team to understand whether this item will affect the Sprint Goal. On your case, this hotfix affects. So you have to escalate the problem to the PO to understand as a team how you can manage the stories in the Sprint Backlog in order to fit this hotfix and complete a done increment with higher value possible.

Probably you will not make a done increment as good as planned at the start of the sprint, but the Scrum Team will handle it to make the best they can do considering the urgent unplanned issue.

At the end of the sprint, use the Sprint Retrospective to find ways to minimize this kind of issues.

Whenever there is an urgent customer support ticket, which is the most important company value, engineers mark it as hotfix, the product development team notices it during the daily scrum and decide to move it into sprint

What criteria is used to clasify this ticket as something that must be corrected right away? Remember that during a sprint no changes are made that would endanger the Sprint Goal, which is the most important thing now.

In the case of technical debt, defects can be classified on impact. Both stakeholders and scrum teams have to live with technical debt and development cycles simultaneously, so a level of impact is set as a threshold and a reasonable ammount of time is spared to deal with. Depending on your volume of defects this time varies and can be agreed during planning. If the volume is overwhelming then I'd take a look at the quality procedures being applied among other measures. There's a lot of helpful information about reducing technical debt elsewhere that might be of use.

In the case of other nature, like for example new stories, functionalities or requirements the thing turns to be easier. There's a role within the scrum team accountant of these matters that deals with value. 

My point here is that you (scrum team) have the control and the power of decision on everything that affects your work and the value delivered along, and you are in the position of deciding what must be urgently covered and what might wait for the next cycle. Get to a balance.

Hi Dolevo,

I'm not sure how many this happens to your team, but I recently started to coach a team that was well into a year into their Scrum journey. The thing at this was that they didn't really do Scrum, more of the most severe case of Scrumfall I've seen thus far. They had Test Sprints, Integration Sprint, the only measurement of value was the quantity of features developed etc etc. You can guess it; they had a huge amount of technical debt, with severe bugs popping up regularly. 

As soon as I started, the team started to focus on quality instead of quantity, and reserving 10-15% of their time in a Sprint to deal with the bugs as they came up, gradually reducing technical debt. Other technical debt that was discovered in the mean time that wasn't that severe, was put up on a Technical Debt Board on the wall. This made the amount more visual and tangible for everyone to see, raising transparency. This was an opportunity for management and all stakeholders to grasp why quality was so important and why this gets priority over quantity. 

Just a very summier resume of what happend, but maybe it's something that would help you in the future. 

This is a common issue in my experience when teams have responsibility for both feature development and run-time support.   I believe this is ultimately the root cause, and while there may be effective ways of managing it, they all seem to be workarounds in my opinion.

Finding out a way to isolate the Development Team from such interference (Scrum Masters ==> Protect the Team!), so that they can focus on sprint work and the Sprint Goal, should be the real mitigating objective here. 

Hello Dolevo, 

I have some experience with Operations team and i understand that high priority issues keep coming in your bucket unannounced. 

In this case , you need to accept PBI's or user stories in a sprint accordingly. Sprint goal should not be endangered (Ever). You need to plan "Sprint Planning" event effectively. 

I hope, i  answered your questions.