Toggle Menu

Insights > Agile Transformation > Let’s Sharpen Your Agile Ax … It’s Story Splitting Time

Let’s Sharpen Your Agile Ax … It’s Story Splitting Time

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 […]

By

October 19, 2016

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.User Story (Not Shared Understanding)

In this next step, the user story is acting as a placeholder for a conversation. When the conversation does occur the misunderstanding is realized.

User Story (Explain Understanding)

We then continue the conversation until we have reached a shared understanding of the need.

User Story (Conversation towards understanding)

And, voila, we now have a shared understanding.User Story (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:

User-Story-and-Description

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:

User-Story-Acceptance-Criteria
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:

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:

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.

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!

Category: Agile Transformation

Tags: Agile

You Might Also Like

Professional Development

Inspecting and Adapting Myself

“Between stimulus and response, there is a space. In that space is our power to...

Agile Transformation

9 Methods to Get More from Your Agile Adoption

Getting started with Agile is straightforward; succeeding with it is challenging. You can’t just introduce...

Agile Transformation

9 Signs You’re Struggling with Agile Adoption

Your team adopted Agile to get better—to accelerate delivery and improve performance—but now that you’ve...