DevOps & Scrum

Can you clarify what you mean by ops being a relative unknown? If it involves work for a particular product, shouldn’t that work be accounted for and described on the Product Backlog?

Before answering the question, it's important to consider that one of the Scrum Values is focus. Whatever the responsibilities of the team, we should respect that they will have a better chance of achieving their objectives if we help them to focus.

We should also remember that Scrum is built around self-organizing teams. We should support teams in arranging themselves in whatever way they see fit, but set expectations and provide accountability for the outcomes, so that they can continue to improve, and reorganize when it's needed.

One possible option would be to have a single team that is responsible for supporting what they develop. This would provide an extra incentive for the team to minimize the amount of support that has to be provided. For instance, if a team notices that by implementing poorly designed features, it has to provide more support, it will find it easier to spot opportunities to improve its development process, and to resolve pain points for customers.

The team will presumably benefit from closer ties to the customer.

In terms of timekeeping, there is a significant chance that the amount of time this takes from the team could vary from day to day, and sprint to sprint, but there are tactics to bring this under control.

One such tactic could be to set a policy of when it will take on support requests that come in. This could be considered as an SLA (although I caution about treating it in the heavily contractual way that many SLAs are used). The team, could for instance accept that specific types of incident, question, bug fix, etc. are all to be treated as a higher priority than other work, such as achieving the Sprint Goal, or to be investigated/resolved within a certain time period.

The team could also define policies of how the work is reported to them, what it considers enough support, and at which points, work should cease for the customer, or be escalated to the Product Owner to be potentially added to the Product Backlog. 

Although there will always be some variance, if a consistent approach is taken by the team, they should be able to predict (within a certain margin of error) how much support they are going to need to provide, and then provide a realistic forecast during their Sprint Planning.

I'm thinking the idea of Team B is bad, since we don't want to go back to the days of a product team throwing stuff over the fence at an Operations team.

In which case, assuming it is Team A, how would they fit the support work into time management? Ops is, of course, a relative unknown, so if Team A needs to deliver on their sprints, they may get waylaid if there are issues with support?

What you are describing is how the teams I currently work with operate. The teams are responsible for developing and maintaining the code base for the product that they work in. In order to be able to deliver for the sprint goal, but also address any important issues that come up, we only plan for 80% of the team's capacity to be used for the sprint backlog and achieving the sprint goal. The rest of the time is buffer for any major incidents that need to be addressed, or the team may have the capacity to address support issues with their extra time if they finish the sprint goal. 

Ideally the PO will prioritize support issues along with features and enhancements in the backlog. Now when sprint planning occurs, you may have some high priority support issues to address in your sprint along with other work to deliver the goal, but this is generally still only 80% of the team's capacity in our case. 



If you are talking about support issues that need to be addressed as soon as they are found, these are generally escalated by a team member or the PO to the rest of the team, and some negotiation may need to occur on what will/will not be completed in the sprint in order to address the issue.

I think they key take away is that you shouldn't plan on your team focusing 100% of their time on the sprint goal. There needs to be some buffer in case of fires, sickness, or any other random thing that may come up. There should also be some process in place on how to deal with an urgent support issue (ie, will the team need to remove something from the sprint because they can no longer deliver it if they address the support issue instead?). 

... we only plan for 80% of the team's capacity to be used for the sprint backlog and achieving the sprint goal. 

Same's true in my current (and two previous) setup(s). Works just fine.