Do you struggle with completing stories within an iteration? Do you have trouble splitting stories that still have business value? If you do and are in the DC area then stop on by my AgileDC workshop on October 24th called, “Let’s Sharpen Your Agile Ax, It’s Story Splitting Time.” If you aren’t able to attend or want a sample of what will be presented, I am going to cover one of the easiest and most effective story splitting techniques in this post.
User Story Baseline
First let’s level set on what a user story is and what it isn’t. The user story should be a vehicle for continued conversation describing a chunk of the product to be built. It shouldn’t be a stand-alone detailed description that on the surface doesn’t require further conversation. Even if digital space is free (e.g. you use JIRA or something equivalent), try to keep the stories short enough to still fit on a 3×5 card. The story should provide a shared understanding of the business need.
I love the graphical depiction below in Jeff Patton’s book, User Story Mapping. It illustrates the value of the user story and how we reach a shared understanding through continuous conversation.
For some context on the graphics below, the yellow figure could be a user, blue figure a product owner or business analysts, and the red figure a developer or tester. In the first scenario we have written everything down and passed it off to the next group to work on it with minimal conversation assuming that it was documented with perfect clarity.
In this next step, the user story is acting as a placeholder for a conversation. When the conversation does occur the misunderstanding is realized.
We then continue the conversation until we have reached a shared understanding of the need.
And, voila, we now have a shared understanding.
User Story Format
For those unfamiliar to a typical user story format we have three parts, the who, the what, and the why. That will look like this
Front of User Story 3×5 card:
Each story will have acceptance criteria that lets us know when the story is done. Writing good acceptance criteria (AC) can greatly improve shared understanding. Each AC should be indicative (true/false), unambiguous, and complete. It is also helpful for AC to be in present tense and written so they are false prior to development and will be true at some point in the future (after user needs are met).
Back of User Story 3×5 card:
Acceptance Criteria Examples
For example, we may have a story that goes a little like this.
“As a mobile user, I want to be able to find and purchase high quality products at a reasonable price, so that I can save money without sacrificing quality.”
Bad AC might be:
- The search returns quickly
- I want the search to return accurate results
- I want results to be in order
So why are the AC above bad? The first and second have the words “quickly” and “accurate,” these are very subjective. The third specifies “in order,” this is ambiguous and leaves much to be misunderstood.
Good AC might be:
- I can sort the search results by relevance, best seller, or price
- I can filter the search results by manufacturer, price, or rating
- I can add items to my shopping cart
- I can purchase items in my shopping cart with a credit card
- The search results are returned within 1 second on a 4G connection with 4 bar signal strength 95% of the time
Splitting on Acceptance Criteria
Once we have well-formed acceptance criteria the splitting becomes quite easy. Each of the acceptance criteria becomes the what/action part of the smaller story and we add who it is for and why they need it.
Let’s take the first acceptance criteria and see if we can’t make it smaller and still have value.
- I can sort the search results by relevance, best seller, or price
This could become:
“As a traveling business owner user on a mobile device, I want to sort the search results by best seller, so that I can purchase an item that I know people like.”
We were able to maintain business value because if we developed this and put it in front of users, we could get feedback on whether it met a need. We were also able to hone in on a more specific user and purpose that can help with prioritizing.
The other types of sorting were left out because those can make separate user stories to be implemented. This is an example of conjunction (e.g. and, or, as well as, <commas>, etc…) splitting, another useful technique.
This AC splitting technique will be covered in more depth as well as 3 other techniques at my AgileDC session. Stop on by and sharpen your Agile ax!