I'm wondering about what a typical user story for DevOps tasks should look like, especially in tools like Jira. The usual format of 'As a [persona], I [want to], [so that]' doesn't seem to fit well, particularly when it comes to the 'persona' part. I'm also skeptical about using Gherkin notation (the given-when-then structure) for acceptance criteria. Can anyone share some examples or best practices? How are your Product Owners approaching this?
5 Answers
I think the Gherkin format can be hit or miss for DevOps. There's definitely a need for flexibility in how we document these tasks. Sometimes the titles are just straightforward, like 'X is broken,' and we end up troubleshooting from there. Keeping it practical is key.
I generally describe the issue or task concisely, adding any thoughts about how to solve it, and then I tag any relevant teams. I frequently include comments on progress or any blockers I encounter during the task. This way, everyone stays in the loop and can see updates as they come.
In my experience, we often skip detailed user stories and just use regular tickets for DevOps tasks. For instance, if we're nearing end-of-life for our production VMs' operating systems, our ticket would look something like this:
**Title:** Prod VMs OS reaching EOL
**Description:** Our production VMs’ OS will reach EOL on [DATE] and won't receive security updates. We need to redeploy development environments to the newest LTS version to verify all workloads before we proceed with production.
I've found using Kanban works better for DevOps rather than formal Scrum or Sprints. It allows the team to focus on delivering without getting bogged down by excess processes. The priority should be getting the work done efficiently!
I've been writing my own user stories and usually avoid the typical 'persona' structure. Instead, I prefer a straightforward description of what needs to be accomplished along with a section for any tech hints or development tasks. This keeps it clear and focused on the work at hand.
That’s a solid approach! Capturing the essential information without the fluff definitely makes for a clearer process.