Automation and Measurement as first class citizens in your sprint backlog
When you start work on a product, your velocity may be low and not reflect the investment you need to make to have proper continuous delivery. Here’s an idea to make it visible.
The soda factory analogy
When you build a soda factory, producing your first can of soda effectively costs as much as the entire factory. Of course you plan to produce a whole lot more, and distribute the cost over your planned production.
This is an analogy that’s worth considering when starting on a new product with your Scrum team. During the first few sprints of work on a product, a team is often busy setting up the delivery pipeline, test framework, local development environment, etc. All this work undeniably has value, but usually isn’t expressed as "product features".
For example: You have 20 similar functional user stories that would be an equal effort to implement. The first 2 sprints your functional burndown is low. This is because during sprint planning, whichever user story gets picked up first has the questionable honour of having subtasks such as "Arrange access to Browserstack", "Set up Jenkins", "Set up AWS account", "Set up OpsGenie for alerting" and "Set up Blazemeter for load test", to name a few.
The Scrum Guide on the deliverable increment
Consider what the Scrum Guide says about a deliverable increment:
Incremental deliveries of "Done" product ensure a potentially useful version of working product is always available.
a "Done", useable, and potentially releasable product Increment is created
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done". An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.
Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.
This is problematic because it means your first few sprints tell you little about your ability to deliver value given the manpower and knowledge at your disposal. Also, it may mean your first few sprints fail to deliver any functional increment that could go live. Because what you’ve decided constitutes value is different than what you’re investing in, it may feel like you’re forced to do necessary work without seeing measurable results. You have little to demo during your sprint reviews. Product owners get nervous the longer this takes. You’re destined to be off to a poor start.
See the following sprint backlog and resulting velocity chart. When you hide all the automation and measurement boilerplate work as subtasks underneath whichever user stories you pick up forst, your burndown charts give the impression you achieved very little.
This doesn’t seem fair.
Some resort to starting out with a "Sprint 0" of undefined length and without a sprint goal, to just get all the ramping up out of the way, as though it’s a necessary evil. Don’t do this. Focus on delivering value from the start.
Automation and measurement as first class citizens
Let’s reconsider what constitutes value for the product owner, and thereby what our initial definition of done is.
After all: it is the team’s right to adjust the definition of done as it progresses through its sprints. It’s relevant to both feature teams and component teams, though more so for the prior. We need to uncover the heuristics we use to deliver value, and see them as part of that value.
Consider CALMS, which describes a set of DevOps best practices.
-
The A in CALMS stands for automation: Automate your delivery process. Setting up Jenkins or GitLab are tasks that should be measured in your velocity and considered as valuable increments.
-
The M in CALMS stands for measurement. One reason for wanting to be agile is that you get to focus on feedback loops in your delivery process. So building those feedback loops is value. This means setting up SonarQube, Twistlock, OpsGenie, New Relic, CloudTrail, etc can constitute valuable increments.
So when you express work that delivers on Automation and Measurement as first class citizens in your backlog, what would this effectively look like? Let’s take a look.
This way, your velocity more adequately describes the valuable work you’ve done for the continuous delivery of your product. After all, it isn’t so the product that is valuable, but your ability to respond to the market and adjust the product. As stated in the Agile Manifesto:
"Responding to change over following a plan."
Caveat: Focus on unique value over crosscutting concerns
When multiple teams have the same requirements in this area, you wouldn’t want each of them to pick this up individually. Ideally, a team invests in the things that uniquely belong to them.
-
In SAFe a System Team takes this responsibility.
-
In Nexus such crosscutting concerns might be picked up by the Nexus Integration Team.
Either way it’s important to understand though that eventually, the ability to deliver a product is the responsibility of the team building it.
Caveat: Avoid technical user stories
Be wary of "technical user stories". The development team should avoid creating a backlog of fine grained technical user stories like "Write a RestController for feature X" or "Write a test for feature Y". Always focus on features as first class citizens that are either done (including tests) or not.
