I've been wondering what a typical user story for DevOps looks like, especially in tools like Jira. I feel like the standard format of 'As a [persona], I [want to], [so that]' doesn't really fit well for DevOps context, particularly the 'persona' part. Also, I'm not sure Gherkin notation (the whole given-when-then setup) is suitable as acceptance criteria for DevOps tasks. Can anyone share their experiences or examples? How do your Product Owners (POs) approach this?
6 Answers
I don’t bother with user stories for DevOps. We generally only write regular tickets. POs often focus on features or epics rather than dev tasks. We create our own tickets for ops tasks that need attention, which keeps things clearer and focused.
When I create tickets in Jira, I highlight the issue or task, share some thoughts on how to tackle it, and mention relevant teams. I also track my progress and blockers in the comments. My PRs are usually named in a way that links back to Jira too, like 'feature/JiraTicket.' It streamlines the whole process!
I wouldn't stress too much over strict user stories for DevOps. I believe Kanban approaches work best here. They're much more flexible than SCRUM and allow the team to focus on getting things done without all the extra overhead.
A simple version of a user story could be: 'As a user, I want to use the pipeline, so that my build works.' However, that can get tricky for infrastructure tasks. Often, the user isn’t the one using the pipeline directly, so I think focusing on the value to developers is more important than strict user stories.
True, and the personas can get confusing. For infrastructure work, I feel like simpler tickets can be much more effective. For example: 'Title: Prod VMs OS reaching EOL.' That gets the job done without the fluff.
Sometimes, I find tasks are labeled just with a title like 'X broken.' It's all about troubleshooting from that point. That said, I think versatility in how we write tickets is key. Not everything needs to be a traditionally formatted user story.
In my experience, we usually skip all that complicated format for user stories in the ops or DevOps space. Instead, we focus on a straightforward description of the task at hand, often paired with some technical hints or a list of dev tasks needed. It keeps things clear and to the point.
I totally agree! If our task needs QA testing, we might assign a point value to it, but otherwise, we operate on the principle of 'done when it’s done.' It's more about getting the work right than fitting into a rigid points system.
Exactly! Kanban fits nicely with DevOps. We can adjust and adapt without being bogged down by formalities.