What Makes A Good Backlog Story?

Requirements vs Design vs Delivery

Another quick, softer skills blog post relating to the ‘art’ of writing good backlog stories.

Background

Building on the post I recently wrote about Defining Technical Debt, one of my customer delivery teams when on to ask about backlog hygiene as part of their agile working processes. Specifically, regarding the writing of stories or work items. I’ve therefore put together the following post to offer my opinion based on experience as a solution lead.

Capturing what, why and how in a delivery teams backlog following a well-designed solution is the most important part of a successful project. Because ultimately, if the detail and definition is missing from the backlog how can anyone realistically deliver what is required in a scalable way. For me, the following popular image comes to mind and gives an amusing, but worryingly realistic perspective on what can happen when design turns into delivery. Without clear business requirements captured.

To address some of these problems lets write good backlog stories that can be agreed upon and used by delivery teams. Stories that avoid any doubts or ambiguity regarding what needs to be done.

Scenario

To support this post and help make the point about a well written story I want to establish a typical scenario relating to a hypothetical data mesh architecture delivery project. We can then use this context to drill into examples of what would make a good backlog story as part of the delivery scenario.

Going deeper into the situation, I’m going to say we have a backlog epic to deliver a data mesh architecture for a business function.

The epic includes features for the nodes of the data mesh, covering core services and other platform components. Then specifically, we have a feature being worked on for a new data product within the mesh. This product requires a data analytics solution, to be simplistic, for now. The solution includes the need to deploy a Data Lake storage resource within our Microsoft Azure cloud platform.

Let’s write a story covering what, why and how for this Data Lake resource that could later be picked up by the delivery team.

Story

I’m going to breakdown our scenario story as follows with headings and example content that I’d expect to see in the left-hand column. Then narrative covering the content in the right-hand column.

Story Elements Example Content	Supporting Narrative
Title Deploy an Azure Data Lake Storage Account	Offering a short summary of what is required.
Description As a (data/platform) engineer I need to deploy an Azure Data Lake Gen2 storage account within the data products provisioned Azure Resource Group to house all persisted datasets required from ingestion through to modelling for the delivery of a data analytics platform.	Offering context that supports the understanding of why this is required and who lead the delivery, in terms of a technical persona. The style of writing here can differ along with the target persona, but the point of including why and who will always remain.
Method Using established platform resource templates from the central ARM/Terraform/BiCep asset marketplace extend the infrastructure deployment pipelines for the data product to include an Azure Data Lake Gen2 storage account resource. See: https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview	Offering details about how this should be done for a particular environment and toolset used by the business. This could also include links to references and examples internally or externally covered by the business that support the preferred development method.
Configuration The Data Lake storage resource should be deployed and setup according to the following specifications: – Subscription XXX – Resource Group XXX – Naming Convention for Account XXX – Target Azure Region, UK South – Geo Redundancy Enabled – TLS Version 1.2 – Hierarchical Namespaces Enabled – VNet Integration to Network XXX – Folders to be created (Raw, Cleaned, Enriched)	An extensive configuration list to covers the exact specification for the component developed as part of the story delivery. Specifications will be tailored to the design and deliver requirements and may include code snippets or class libraries for the solution.
Owner John/Jane Doe	A point of escalation for technical leadership and queries. The owner should also take the lead during backlog refinement and sprint planning creating tasks for the story delivery. The owner is not automatically the person doing the work for the delivery. A story could have many tasks that are handled by multiple team members.
Definition of Ready The following solution components should be available to support this stories deliverables: General – High level and low level design documentation is available to support the technical understanding of this stories deliverables. Specific – The target Resource Group has already been deployed. – The target Resource Group has permissions granted for the delivery team and the Service Principals used for deployment automation. – The VNet that will be used to support connectivity for the storage has already been deployed. – Folder definitions and the taxonomy of the storage have been documented.	Covering all upstream dependencies that would/could result in the story becoming blocked if not in place. Where possible the backlog tool should support the linking of stories to inform a delivery dependency chain for specific items. An assessment should be done during backlog refinement to establish if the story is likely to become blocked and therefore not ready for delivery. And not go into the next sprint.
Definition of Done The following checks can be applied to the story delivery as an assessment of completion. – A Data Lake Gen2 storage account has been deployed. – The storage is in the correct Azure Region, Subscription and Resource Group. – The storage has the correct permissions granted against it for user and system access. – The storage account is connected to the required Virtual Network. – The storage account has the correct version of TLS encryption applied.	Criteria that can be used during a potential peer review or pull request that allows wider team members to assess the story delivery vs what has actually be completed for a given technical asset or resource.
Story Points Estimate 5	A time effort estimate that can be used to inform the capacity and workload for a delivery team within a given sprint.
Priority 1 – 5	An indicator that can be used to inform what work should be delivered next in a sprint. Especially where stories have equal time estimates.
Test Criteria Test cases should be applied as follows for the story output: – Integration testing from a compute resource to the newly deployed storage account including the copying of data to the configured folder structure. – Functional testing to ensure the storage can be accessed via other resources within the targeted virtual network.	Testing criteria should be used to support downstream requirements for test case coverage and test types that will be needed for the story output.
Tagging Tags added to the story as follows, separated by commas: Infrastructure, Storage, Release 1.0, Analytics	Story tagging in most backlog tools is a helpful way to quickly filter and report on stories with delivery dashboards. This can then support project managers with metric relating to delivery.

Tasks

To complete the picture for a delivery team, I expect during backlog refine these attributes within the story are completed with full details, informed by the solution architect, and populated by the technical lead, or similar. Then during sprint planning tasks can be quickly created with the delivery team engineers online.

In an ideal world, a delivery team would also be given a forward view of all stories going into the next sprint. This allows time to read the story content and understand what is required before tasks are jointly created.

Conclusion

To conclude a good backlog story (including this level of detail) is going to take a lot of time to create/document. However, in my experience, front loading that time and investing it in the story writing process will pay off. Consider this compared to a badly written story that later results in technical debt, re-work, re-deployments and a loss in the teams overall velocity because the requirements weren’t clear during the sprint delivery.