Making user stories and operational duties

Question

I'm looking for some advice on how to navigate the choppy waters of DevOps/SCRUM with in a team.

---

Background: A team is very operational and has 3 products and 2 engineers, 1 Product Owner, 1 Manager (no scrum master, team lead, or tech lead) and their delivery sprint is 1 week. This team follows "you build it, you own it" and also tracks team hours via tasks assigned to stories.

Scenario: For 1 sprint, an engineer found himself working on incidents (application availability affected, due to a mix of upstream systems and the application itself) for half of the sprint. The team decided the remediations were not what customer asks, but instead operational work.

---

This is a real world problem I'm trying to tackle. Obviously, this situation can be mapped well to Agile principles, but this department heavily follows DevOps/SCRUM for product mapping and tracking purposes.

What do you think would be the best way for the engineers to track their work?

Answer 1

If you frequently have incidents and other pop-up work that needs to be prioritized, Scrum probably isn't a good fit. The core of Scrum is the Sprint. If you can't consistently hold a planning session to select a goal and work that supports that goal for the Sprint, execute the work, synchronize with stakeholders, and then improve your way of working on that Sprint cadence, you're going to struggle with Scrum.

The rest of your context isn't well-suited to Scrum, either.

Scrum is built around a team supporting a single product, yet your team is supporting 3. If you were to "do Scrum", you would have three Product Owners and three Product Backlogs. Even if you were to have fewer Product Owners, you should still have three Product Backlogs. However, the team would struggle to focus on a cohesive goal for the Sprint unless each Sprint can be dedicated to a single product. This is especially true if the products are all operational and need ongoing monitoring and potential support for incidents.

The team size is also on the small side for a formal methodology. Unless the manager is actively developing the product as well, you only have two developers. The Scrum framework is designed to coordinate the work among a team, so some of the activities described in the Scrum framework will probably be excessive or even add additional overhead rather than making the team's life easier.

The best course of action would be to look outside of Scrum since the practices there aren't suited to your current context. However, if you are stuck in Scrum, you still have options.

All work that is done in the Sprint must be visible. If there are incidents, they need to be in your Sprint Backlog, on your Sprint Board, and everyone needs to be aware that these incidents came up. When you get to the Sprint Review and Sprint Retrospective, the team needs to communicate the impact of these incidents. At the Sprint Review, should be able to explain the issues that came up and how those impacted the team's ability to achieve the Sprint Goal.

Going forward, the Sprint Planning session should include incidents when considering capacity. If your organization embraces DevOps, you should have extensive monitoring of applications that can provide information about incidents. Using past performance on how long it takes to resolve an incident, the team needs to set aside time and not plan their Sprint to capacity. The Sprint Goal should be generally achievable, considering a "normal" amount of incidents and time to resolve those incidents across the supported systems.

At an organizational level, there needs to be a strong effort to address the incidents' root causes. By reducing the number of incidents or developing ways to restore the system to a normal operating state faster, the team's capacity for development will increase.