Improving Sprint Stories: Include How
I share current insight that improving story process by adding another section to sprint stories: how and when. I walk through new items in detail and what problems they solve.
Dramatically improve your sprint stories by adding these two sections for you, your team, and future owners of the system.
This article will take you about four minutes to read.
Introduction
In my previous article on writing stories, I emphasized writing why and what aspects.
Now, whenever I have to write a new story, I following the template. It helps separate out the motivation and the end result with the different sections.
With my background in understanding the system and I can still dig into the system’s guts, I see stories differently. This ability is a blessing AND a curse that I know how the system works and so tempted to just write how to solve the problem. That knowledge can be just the “desired state”.
I get so caught up in writing and thinking of the end result and end up writing (or allowing such stories):
- Add a column from the table
- Send notifications
- Remove data
Stating the desired result is great to separate my desire from how to implement something.
At the same time, the desire of describing how to implement the story is in the end result.
New Sprint Story Section: How
After writing more stories myself and reviewing past stories, even following the rules of having why and what in the story, I found adding this one sprint story component makes a good story, great.
HOW
HUH?? HOW? In the previous article, it says don’t include how. Now the guidance is to include how?? Right HERE!
What happened???
Well, not, “how to do the story”, this how is:
How will the stakeholder test for the desired result??
As the person writing the story, who may be or represent the stakeholder (the original requester of the feature in the sprint story):
- Why: gives the motivation for the story
- Current state: the present solution (if present)
- Desired state: ultimately, the result the stakeholder expects
- How: the stakeholder will test for the desired result taking these steps
By explicitly stating how the stakeholder will test for items in the story it forces the story author to think how to verify the work. If the author can’t validate the work at a level that benefits the user, is the story beneficial or even written at an appropriate level?
Stakeholder Perspective
If I choose to use all the technical tools to validate the work by looking at the code, the data base, the endpoint response, etc. the stakeholder, who I am writing the story for, should use the same tools themselves.
In our system, that is not the case and the stakeholders would use higher level tools to validate, which changes the scope of the story, which changes the desired result.
This also allows less technical specification (or technical how-to implement recipe) stories. Where the stakeholder would test for the feature at their choice. Maybe even at the same level as, the end-user.
By writing desired state at a higher level and describing how the stakeholder would test for end result allows the development team has greater freedom in approaching the problem. Where they can choose different solutions, break stories down further, and/or deliver incrementally.
The QA team knows the perspective of the stakeholder takes in validating the solution, ensuring testing that path, along with any others.
All of these allow for a better sprint delivery process.
Future Owner
Another great benefit of including HOW to test the feature: future story owners can understand WHY the system has the feature, what were the current state, the desired result from the stakeholder, and know how to test for the story result as the original stakeholder would!
Benefit
This how to test benefit came to light when I recently investigated a user query on a past feature. When I looked at the original story, it covered WHAT aspects well, the WHY were so-so. Either case, I wanted to find out as much detail as possible.
As this was in a different part of the system, it was new territory for me. I’m basically a new manager taking over part of the system and I want to get up to speed fast. Reading past story regarding the feature is the best way to know how to answer the user’s query.
From just the story with the result, I understood. The details was not sufficient for me to replicate how the result worked (the main user query.)
Without seeing HOW the stakeholder would or wanted to test for this feature, I zero chance of validating the user’s inquiry about the feature from just the result declared in the story. I would have to… gasp dig into the code.
Optional: WHEN
Another thing to have that would be useful in story is the WHEN. As in: when is the result expected??
Depending on the desired result, when will affect the amount effort to implement, have the team decide whether to take shortcuts or incur technical debt to deliver.
For stories that finish within a sprint, when is the length of the sprint.
Having a when section would be beneficial for larger multi-part stories or even epics to keep the team on track and let them work backwards against the deadline.
Nothing Inspires Like A Deadline!
Conclusion
I’ve shared a recent epiphany in improving sprint stories: adding a how will stakeholders test for the desired result? section. A step-by-step expectation here goes a long way, from helping stakeholders formulate exactly what they want, to clarifying end results for the developer and Q&A teams, and even for future owners of the system to learn how to test the feature quickly.