Sprint Stories Section: How Stakeholders will Define Success?
I want to share an issue I found in my current story structure, the proposed improvement I want to have, and my thinking on why this improvement will make the story stucture even better.
I go over the story structure, other ways I have applied it in my work, and how I can improve a weak section of it.
You will get a story structure to use to gather requirements, think through larger projects, and maybe even start to like JIRA. (No guarantees on the last one!)
This article will take you about three minutes to read.
Introduction
I wrote how structuring sprint stories in a specific format improves clarity and meets a team’s needs:
I enjoy this structure as this structure is scalable across organization, from implementation level to product owner level, as we all care about the same thing: getting everyone aligned to do the right thing.
- why are we doing this? (why)
- who are the customers? (stakeholders)
- how large will this work intended to be? (scope)
- what’s happening now to solve the problem? (current state)
- what do we want to do about it? (desired state)
- how to verify desired result? (how will stakeholders test)
The best thing is the structure detangles:
- the “why” from the “current state”
- “where we are now” from “where we want to go”
- “a recipe on how to do it” from “these are the things stakeholders will test for in the result”
Beyond Feature: Epic
I have applied this structure to “epic” level, gathering requirements from high level stakeholders so the team can derive implementation stories from the epic over the course of the sprint.
When “new information” comes from stakeholders during the epic, there’s a flexibility to derived stories.
The implementation stories use similar structure to keep everyone on track as it helps them think through a story before even laying out any code or tests.
Thinking Through Large Problems
Using this structure, I have scoped out large changes to the system with stakeholders in a manner that meets both of our needs. Using the last section: “how will stakeholders test” as a way to think through specific scenarios and cover edge cases so they are not “edge cases” in code.
New Members
The story structure serves everyone well, even for new team members coming in, either as an individual contributor (“how does the team get work done?”) to manager (“what does the team need from me to get work done?”)
Story Tracking
Through consistent application of this structure in JIRA, I have grown to appreciate JIRA’s capabilities. Where one can determine the history of the work in a different context.
Improving
One area where I noticed hestiation when others follow the structure is the newest section: verification.
The label of: “how stakeholders will test” just hasn’t been that straight-forward and I found I need to follow up with this from contributors, especially at higher levels.
Relabel the “how will stakeholders test” to: “how stakeholders will define success”
Reasoning
The word “test” doesn’t have such a positive connotation all the time and can be different the further away from the implementation.
The further the stakeholder is from the implementation, the less likely they will “test” the work directly. Such as:
- “the user will be able to complete the action with less than X clicks” vs.
- “the user won’t complain about how much work it takes the action to complete”
If the story author is not the stakeholder, it will be easier for them to go back to the stakeholder and get an answer to the question: “how will you define success?” instead of: “how will you test this thing works?”
Also, who wouldn’t want to “define success” over “figuring out tests”??
Conclusion
I am enjoying following this story structure in a group setting and found it is valuable to get everyone’s requirements together in a manner that provides structured details for implementation.
I have taken the stucture to a higher level and using it for epics, thinking through larger problems, getting new team members productive either as contributor or as a manger to the team.
The structure lends itself well to tracking through JIRA, which blows my mind away. Have I been JIRA-ing wrong the whole time?!
As much as I want to say this is the “only story structure you’ll ever need because of this, that, etc.” there’s an improvement: changing “how stakeholders will test” to: “how stakeholders will define success.”
I believe that small change in connotation will improve market acceptance of this structure and take it further.