So, how do you write development stories that describe your journey through a project? How do you avoid the pitfalls of seemingly disjointed backlogs that feel aimless?
In the process of managing a project, it’s inevitable that you will need to write some development stories. Stories are the building blocks with which we organize feature priority, identify bug fixes, and gain insight into our development progress.
A well-written story communicates how we are expanding our application. It points to a future rich with user workflows and helpful features, but it can be easy to create a disjointed view of this world. This may not be a fool-proof solution, but here I’ll describe three tips that help me write context-filled concise stories.
Build up the story.
Understanding the purpose of the work relies on a cohesive story. Having a well-defined purpose will enable developers to ask the right questions and connect this work to the larger whole. This context can be hard to convey, so, as a guideline, mapping out how a user landed on the page and what they will do now can help. Sometimes this can be straightforward, but when the context is missed, you could end up paying for it with rewrites later to align with the overall workflow.
Define done.
Defining “done” is one of the pillars of agile stories, but the purpose can be easily overlooked. Avoid expressing how to build a feature and, instead, define what the application needs to be capable of when it’s done.
If the story is a new endpoint, define the interface; if the story describes a new webpage, express what the page’s purpose is in the user workflow. And, if the story requires logic changes, give examples of changing expectations (valid outcomes and how they differ). It is easy to quickly say the definition of “done” is “has x feature,” but this leaves the developer holding the bag trying to cover all of their bases when finishing a story.
Target the right audience.
Know who you are writing the stories for. The stories required of a new project can (and should) differ significantly from stories six months in. The story’s level of detail should reflect the current comfort and familiarity with the project. As the developers build, the stories that describe future work will be larger, contain more comprehensive tasks, and, in turn, include less detail. When gauged correctly, the decrease in detail is supplemented with developer domain knowledge.
One caveat to this step is that adjustment is required when a new developer ramps on. The existing knowledge base has changed, and stories should reflect that. However, it is also reasonable to mitigate this by writing stories based on who will be assigned. This leads to bifurcation of the story pool based on who is able to pick up stories. However, this can be merged down the road once the developer ramps up.
Tell a development story with your backlog.
Hopefully, these three tips for writing stories will help you construct a backlog that tells a story. Building a workflow piece by piece and story by story will drive development and clearly communicate each story’s purpose. The level of detail may change, but the tips outlined above can help to steer a project from beginning to end.