NB: In our company's internal lexicon, "DevOps" is a role set by our company that means "infrastructure and operations person" rather than standard DevOps. I know it's more of a culture thing but I missed clarifying it in my original question due to company speech blindness.

Reading through Should a designer or a devops be a member of a Scrum team? + Including UX in Scrum there seems to be a general consensus that UX/Infra/Ops people should be full scrum team members.

Our teams currently have 2-3 backend developers, 2-3 frontend developers, and 1 infrastructure/operations person.

Trying to accomplish that in our team we face issues during the planning phase of a sprint:

  • Most of our User Stories don't require Ops/Infra work, which leads to issues when planning a sprint for the whole team.
  • There are Ops/Infra tasks/stories that have no relation to development stories for example: "update library/service X on beta"

This leads to issues where frontend devs are not happy because they have to estimate "server stuff" and Infra/Ops are not happy because they have to estimate "refactor JS service XY" during Sprint Planning.

I think the ideal long term solution would be to have all people on the team learn and expand their knowledge but that is just not the current state. I'm not sure if everyone in the company is committed on making everyone capable of working on all tasks.

Should we just accept the "overhead" that exists in those meetings until enough knowledge is shared or should we plan ops/infra tasks outside the Sprint? Should maintenance stuff be separate, or are there any other practical solutions for this?

3 Answers 3


There's no such thing as "DevOps people".

DevOps is an organizational culture. Like how Agile brought the business and developers into a close, collaborative relationship, DevOps is about a close and collaborative relationship between development and operations, with the end goal of making it faster and easier to make a change and put that change into production, while ensuring the overall quality of a system. The result of a shift to a DevOps culture is the elimination of silos and hand-offs between a development organization, who is responsible for eliciting requirements and building a system, and an operations organization, who is responsible for putting changes into production and supporting (monitoring, maintaining) the system.

Just like in development, there are many roles associated with operations. A few examples of operations roles include help desk or technical support staff, network administrators, database administrators, network architects, various security and incident management roles, among others.

From a team's perspective, good teams moving toward agility should be trending toward being cross-functional. That means that the team, to the extent possible, has the knowledge necessary to take on work from start to end in the workflow. But some skills are highly specialized or not needed on a day-to-day basis, so it may be more about teaching the basic skills to multiple members of the team while making sure that there are sufficient experts to support the teams as needed. It doesn't necessarily mean that each team has an expert in every possible subject matter area.

There's no one-size-fits all answer. In the immediate term, you need to support the teams with the people that you have. For the longer term, you need to decide which skills will be embedded on the team and which skills will exist in a shared pool available upon request. You can also identify people who may be interested in developing new skills, and how the existing experts can serve as teachers so teams can have some knowledge internally and rely on the shared pool of experts for more difficult tasks.

  • hi sorry DevOps people is the role set by our company I know it's more a culture thing but I missed clarifying it in my question due to company speech blindness g I meant people with more infrastructure knowledge. Thank you for your answer to me it looks like maybe whats missing in our company is definition of what should be pool skills on request and team skills
    – gries
    Apr 20, 2022 at 12:32
  • 1
    @gries Yes, figuring out what skills you have and who has them along with what skills you need and the demand for those skills will be the first step in figuring out what to do with respect to putting the skills on the team or putting the skills in a pool for all teams to draw from as needed. Without that information, it's hard to give any concrete suggestions.
    – Thomas Owens
    Apr 20, 2022 at 13:03
  • current situation basically is: a few ops/infra ppl that don't want to code (php/js) 3 scrum teams developing a php/js application, with maybe very few that want to know how hosting, ci/cd etc. is working. I'm the first person to that is doing dev + ops work, so we try to plan ops during sprints, but other ops ppl are working with kanban which leads to an organizational gap
    – gries
    Apr 20, 2022 at 13:25
  • 2
    @gries There doesn't have to be a gap. If you wanted ops to be a shared pool, have your teams plan their Sprints. During refinement, flag work that is likely to require infrastructure expertise and get ops involved in refining it. As the Product Owners order the Product Backlog, they should consider the work with flagged dependencies to make sure they aren't overloading the ops/infra team in one go. As the work comes up in Sprints, the ops team can plan on having one or more people support the Scrum Teams based on when items are selected in a Sprint Planning session.
    – Thomas Owens
    Apr 20, 2022 at 13:51


While DevOps is not orthogonal to Scrum, Devops and Scrum are not synonyms. In addition, there is no "DevOps" role in Scrum. Everyone but the Product Owner and Scrum Master (let's see if I we can start normalizing the term "Scrum Referee" instead!) is simply a Developer.

The fact that infrastructure and operations work is part of Sprint Planning should be embraced. It is the job of the Scrum Master to coach, educate, and facilitate this collaboration, not to find ways for the team to avoid it.

Analysis and Recommendations

This leads to issues where frontend devs are not happy because they have to estimate "server stuff" and Infra/Ops are not happy because they have to estimate "refactor JS service XY" during Sprint Planning.

Good. This is exactly as it should be. Scrum is based on empirical design and just-in-time planning, while frameworks that use Scrum (e.g. SAFe) call what you're doing architectural runway. In either case, it is the responsibility of the whole Scrum Team to call out dependencies and plan for them during Sprint Planning.

Whether or not your team is T-shaped or I-shaped, how do the Developers plan to test and deploy work if no one on the team is thinking about "server stuff?" How will your Developers with infrastructure or ops skills successfully contribute if no one on the team is taking responsibility for upgrading the Node.js Kubernetes pods when needed?

While it may not be possible in your organization to have T-shaped people with cross-functional skills assigned to your team, and while they may not currently see the value in each other's work, the reality is that it's your job to facilitate the collaboration between them and to ensure that the whole Scrum Team (including the Product Owner and the Developers) treat infrastructure and operations work as part of the Definition of Done for each user story. In turn, doing that requires that infrastructure and operations tasks need to be included in Product Backlog Refinement, in Sprint Planning, baked into estimates, and completable within the same Sprint as the rest of the potentially-shippable increment.

The fact that you have people on both sides of this issue saying it's someone else's problem means you have created a JBOP group (Just a Bunch of People℠, riffing off of the JBOD non-RAID appellation) rather than a cohesive team committed to delivering a single coherent increment as required by the Scrum framework, which explicitly states:

Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Taking Ownership of the Problem

Part of your job as Scrum Master is to help your team understand how the framework is supposed to work, and to assist them in removing friction points and silos within the team when they aren't yet ready to do it themselves. Embracing silos or allowing the team to toss things over the wall to other people rather than taking ownership as a team to deliver the Sprint Goal is simply not an option.

The Scrum Team collectively owns their own process and must be empowered to inspect-and-adapt their processes within the framework as needed. Currently, they clearly need assistance in fixing those processes, and may not feel empowered to develop or apply new processes. The is great grist for the mill for the team's Sprint Retrospectives, and supporting this effort is a core expectation for the role of Scrum Master.

Senior Leadership's Role

On the other hand, if the underlying problem is that your organization is broken, then the Scrum Team (and especially the Scrum Master) is responsible for communicating these problems upwards within the organization and collaborating with organizational leaders outside the team to fix it. However, if the organizational culture is too toxic or broken to be fixed, then that is the responsibility of senior leadership since they establish the tone at the top.

Basically, if senior leadership deliberately breaks or fails to properly support the Scrum framework despite the Scrum Team's best efforts, then the responsibility ultimately rests with that leadership team. If leadership breaks the company culture or its processes, then they get to keep both halves. Q.E.D.


Most of our User Stories don't require Ops/Infra work, which leads to issues when planning a sprint for the whole team.

Some suggestions for what they can do in that situation:

  • Spend time coaching other team members on DevOps
  • Work on generic DevOps tasks, such as continuous integration, monitoring, alerting, etc.
  • Allow them to bring work in from other teams or other parts of the organisation

This leads to issues where frontend devs are not happy because they have to estimate "server stuff" and Infra/Ops are not happy because they have to estimate "refactor JS service XY" during Sprint Planning.

Use it as a teaching opportunity. For example:

Front-end dev: "For the benefit of the DevOps team members, this is a reasonably simple re-writing of this service to make it more scaleable. Feel free to ask any questions if there is anything in this story that you don't understand.

As you say in your question, the ideal situation is to have the team learn and expand their knowledge and the approach described should help with that.

  • thank you for the suggestions, would you plan generic tasks like ci/cd monitoring or work from other teams, during sprint planning of the scrum team or would you suggest to do this "out of sprint scope" ?
    – gries
    Apr 21, 2022 at 7:28
  • 1
    I would recommend doing it with the whole team. A planning conversation might go something like this: "I was thinking about adding extra monitoring for our search service as we have had a few production issues with it. Does that make sense to you all?". Apr 21, 2022 at 11:29

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.