Treat DevOps Stories like User Stories

In “Analysing the DevOps Silo”, I made an assertion that the whole team can and should get involved in all types of work. This might mean we lose the pretty colour-coding of our favourite story-management tool, but in turn we gain a way to acknowledge all the work we are doing—whether traditional feature stories, defect fixes, tech tasks or DevOps tasks—as valuable to the business. To do this successfully you have to restructure your mindset about these “technical” stories right from the start and keep that mindset strong throughout the development lifecycle. We have found that following these five tried-and-true activities is a great start.

One of the most valuable techniques analysts use when fleshing out stories is to apply a persona representing who is benefiting.
Tweet this

1. Setting the groundwork with personas

Our first major shift, and one of the most valuable techniques analysts use when fleshing out stories, is to apply a persona representing who is benefiting. Personas can be extravagant creations that define a potential user’s name, skill set and hopes for the system. But often all you really need to get started is a basic person or role. This means that in the story narrative (and yes, our “technical” stories now have narratives), instead of writing:

As a CI pipeline
I want Meta-Runners
So that we follow the DRY principle

...we write:

As a developer
I want the ability to maintain build step configurations in only one location
So that the risk of configuration divergence is reduced

2. Follow the INVEST principle

Just shifting the story’s wording is helpful, but the application of INVEST (Independent, Negotiable, Valuable, Estimatable, Small, Testable) principles is the real value add. Anyone who uses these will tell you it is nearly impossible to perfectly embody them all at the same time. These difficulties lead to the conversations that in turn balance stories as much as possible. Here is how INVEST can be applied to the example story:

• Independent: Other work (e.g., the creation of a new build step or environment) could be done in parallel with this story, and it does not require any additional stories to complete testing or delivery of value.
• Negotiable: Prior to playing, we can negotiate the technical implementation (e.g., by using the TeamCity Meta-Runner option or a scripting solution).
• Valuable: This is valuable to the business by decreasing both time to make changes, and risk in updating configurations. And this is valuable to the development team by reducing tech debt and improving the stability of the build.
• Estimatable: A clear definition of what is in and out of scope allows for easier estimates. This includes build steps, not a limitless refactoring.
• Small: This is similar to estimatable and its goal of well-defined expectations. In addition, we focus on the removal of associated, but unique, value items such as environment variables.
• Testable: The first acceptance criterion is already uncovered; only one configuration change should be enough.

By producing stories that follow INVEST, you are in a position to estimate and prioritise them with the rest of the stories. This was our second major shift. It encourages several behaviours in the team that, in an organic and slow way, lower the DevOps silo wall by doing the following:

• Keeping the entire team’s eyes on the card
• Solidifying the expectations before we get started on implementation
• Cross-functional pairing on defining (and later developing/testing) stories

3. Story kickoffs

A story kickoff is a technique used as a “hand-off” between analysts and developers between stages of the software delivery lifecycle. One common use case is that kickoffs give time for analysts to answer context questions for the developers before they get started. Our third process change goes beyond this basic definition to realize the true value of this ceremony.

In our kickoffs we added the discussion of testing strategies and risks to allow us to better plan for the development process. Sometimes this included the identification of checkpoints throughout development where testing could begin before the whole story was complete, shortening the feedback loop even more. In our story we identified early missing test harnesses, and the need to create realistic test data.

4. Desk checks

Desk checks are the counterbalance to kickoffs and occur after the core development of a story. They include the analysts (Quality and Business) and the developer(s) and are often focused on allowing the QAs to gain any insights from the development process to identify risks and further testing needs. As with kickoffs, we could expand their value by encouraging more focused discussion around the implementation, for example by asking about the use of basic principles such DRY, KISS and YAGNI. A quick walkthrough of changes made gives an opportunity to clarify naming or add additional test cases. Hosting a desk check also backs up the testing discussion in kickoffs, because a desk check requires the setup of data and other dependencies to allow for a thorough walkthrough. At the most basic level, this confirms that the testing phase can begin, but it often has larger impacts by uncovering unexpected branches or missed requirements. Although this provides a faster feedback loop than a tester finding issues once the story is in the testing phase the ideal scenario is to have testers working alongside the developers while the story is being developed, pairing.

5. Including the testing phase

Our suggestion that these pieces of work be tested the same as other stories led to questions about whether this encouraged the “gatekeeper” mentality of QA. It is extremely important that this is not how this approach is implemented or perceived. A QA’s job is not to check up on his or her teammates, but instead to help discuss the story from a different, more risk-focused, perspective. This allows the team to create better software together.

A testing phase for DevOps stories does not always require additional tools or frameworks (e.g., TeamCity or VM fabric). Often we found it to be as lightweight as a simple discussion about implementation and intent. In the cases where more logic is implemented, the developer and QA will pair on the testing process in the same way as they can during the development. This facilitates the removal of the wall between the two roles and further encourages communication throughout the whole team. With DevOps stories you should also be considering concerns like monitoring of environments from your DevOps testing environment to production.

Simple but effective

These five small ideas might seem obvious, but they are really about treating infrastructure stories as First Class Citizens. They apply the same expectations business owners and teammates have of user-visible stories. But let’s be honest: People (both from a development and a business perspective) have a hard time envisioning server provisioning as valuable to the product or business. Instead, by structuring the conversation around the risk of not implementing these stories, we were able to prioritise DevOps alongside product functionality within weeks of applying these simple changes.

This article was originally published in P2 Magazine.