Agile practices like scrum and kanban were primarily designed for software development.

Interrupt and unplanned work is a significant component of what most SRE (Site Reliability Engineering) or DevOps teams do. While it is always useful to use a tracking system like Jira to manage work, do sprint or kanban really work for SRE teams?

The constraints I see are:

  • The work is very dynamic in nature, with priorities changing on a daily basis. Because of this, the sprint duration of two weeks seems very aggressive and it adds unnecessary overhead.
  • People being on call adds another dimension to the problem. Sometimes, more than one team member might get involved in on call / post-mortem tasks.
  • The team doesn't have a single "product" and hence it doesn't yield itself to a common planning process
  • Daily standup meetings may not make much sense because of the lack of overlap among tasks
  • The team might be working on tasks related to more than one partner teams and hence spanning multiple Jira projects. Since a sprint or kanban board allows only one Jira project, it may not be able to fit in all the work.

From what I hear from many SREs that I have spoken to, sprint planning hasn't worked for them at all. I would like to hear from the community here what their experience with sprint and kanban is.

I asked this question on scrum.org as well:

Can scrum be used effectively by SRE teams?

And here is a blog post that raises concerns about Agile and SRE in general:

Agile is Lava

  • 2
    Just a recommendation - I'd spell out what SRE means for those who don't know of the term.
    – Sumo
    Jul 31, 2019 at 16:21
  • 2
    Agile doesn’t even work well for most kinds of software development, why would you imagine it would work well for anything else?
    – Gaius
    Aug 2, 2019 at 5:34
  • I am a doubter, almost a non-believer. I put it out here to listen to folks like you so that I can be sure that I am not ill-informed. Aug 2, 2019 at 6:26
  • First, I think this is more of a software engineering question, not specific to DevOps. Also, there seems there a number of misconceptions being made in this question. I'll address one as an answer, but wanted to relay that Kanban doesn't require backlog refinement, planning, team orientated work or any such notions that are applicable to scrum - it is just a top level workitem organization board. Oct 21, 2019 at 20:28

4 Answers 4


We don't use Agile for the DevOps group ourselves, but we do integrate with the normal Scrum Teams. When something is needed by the team from DevOps, such as optimizing the build server, the related team puts a PBI in their backlog with a 'DevOps' label. Our lead has a custom dashboard in Jira with all issues labeled 'DevOps'. They work with the Scrum Master to get prioritization and then one of the DevOps Engineers is tasked with being an ad-hoc member of that Scrum Team for the life of that issue. This helps us prioritize work based on our "customer's" priorities, ties our effort to the sprint, and allows us to get "credit" for the work we're doing.

Prior to this, we used Kanban on Jira just for a todo list. Unfortunately, we would sometimes have to stop working on something we had planned to work on because one of the teams needed something. Now, unless it's an emergency, they basically request DevOps resources (people/time) via their backlog and the Scrum Master communicating that need to our Lead.


Agile works very well for this type of chaotic environment. However, for the reasons you highlighted, pure textbook Scrum may not be a great fit. As a Scrum Master who does a fair amount of DevOps I've used Kanban boards in Jira to track work.

Kanban Advantages

  • Visualization of the work the team is doing.
  • Identifies bottle necks for the team.
  • Helps keep the team focused on moving work along.
  • Allows for work to be added at any point.
  • Gives visibility to work being done for other teams that are relying on the SREs.
  • Can be generic to cover multiple types of jobs.

While a traditional stand up may not be beneficial, do consider modifying it. A good stand up meeting highlights blockers that a team member may be facing that another team member knows how to solve.


IMO: Yes, Scrum can be used effectively by SRE teams. I have never heard or read that team members can only work on sprint workitems, so it is a misconception that you need to account for all of your time and effort in the scope of a sprint; Also, I feel there is a misconception that all of your work is applicable to sprints. So, convergently, you should manage some work with Scrum and some outside of it.

Scrum, at it's core, is a framework (with artifacts and events) that is flexibly and used for continuous improvement over the nature of work that is accepted by the team (or applicable to such work).

What you need to do is strike a balance between the time and effort you can provide for planned, accepted sprint work -- that you and your team can deliver on -- and the time and effort to tackle unplanned work outside of the sprint.

There is a measure of severity and priority to all workitems. If you're considering Scrum, you should accept work up to a particular severity. You should also consider work that can reduce the severity of upcoming work (if at all possible). I would also recommend you start your sprints with about half capacity (which may be difficult to determine on since relating time and effort in a capacity fashion in the beginning is) - go light. Your team's goal should always be to deliver what work your team accepts, so be picky and don't overextend.

I think the nature of your work is actually comparable to production bugfix work for development teams. Thus, you may want to consult production maintenance teams on their Scrum adoption and success, and Not necessarily constrain yourself to DevOps Engineers experience in program and project management.

  • ah.. I just read Daniel Wilhite's comment in your linked question; Yea, I agree and feel that echos my answer here. I would have upvoted :D Oct 21, 2019 at 21:45

Here is my observation and this is what I follow:

  • Use a ticket for any piece of work that takes an hour or more of effort
  • Keep the ticket updated as and when you make progress on the work
  • Try to set a due date for each work item and try to finish them before that time
  • Set priorities to indicate the urgency level of the ticket
  • Organize work into Epics, Stories, and Tasks if you are using Jira. Use Stories for planned work and Tasks for unplanned work.
  • Make sure only a small number of tickets are in progress at any point in time, to maintain a strong focus
  • Keep updating ticket status (Open -> In Progress, In Progress -> Blocked/Waiting, In Progress -> Closed etc.)
  • Use a dashboard to track your tickets
  • Make sure that no tickets sit in the system for too long
  • If possible, influence your team to follow the same process and have a common dashboard to track team progress

No need to worry about Sprint and Kanban. If you want to really be very formal, start using story points to track effort estimates, but don't waste team's time in task estimation meetings.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.