A Story Splitting Story

This is a true story from a true client I’m working with . The names and details have been changed to protect the innocent…

Story splitting

Several of us were attending a pre-sprint planning meeting yesterday, trying to flesh out the user stories that the product owner was planning to bring to sprint planning in a few days. They are still pretty early in their agile adoption as well as their technology adoption, so there are lots of questions floating around about process and tools.

A story came up in the meeting that described the interaction that a user would take when visiting the site the first time, more specifically around the user agreement presented to them the first time they logged into the site. The story was something like:

“As a user, I want to be to able to accept the user agreement so that I can access my content”

The details of this story included a specific workflow to follow if the user didn’t agree, including errors to show them, and a need to refrain from showing the user agreement again after agreeing to it the first time.

Conversation around this story went on for a while, mainly focusing around the second part, how to handle remembering what the user did the last time they visited the site. There were technical details about where this information needed to be stored that hadn’t been agreed to yet, and team spun a bit around this issue.

The suggestion was made to split the story into two. The first story would be the same as the first, “As a user, I want to be able to accept the user agreement so that I can access my content”, and it included all the acceptance criteria other than the remembering part. The second story would be “As a previously logged in user, I will not be presented with the user agreement, since I had already agreed to it”, which picked up the remembering part.

By splitting the story in this way, they were able to work out the important part for the customer, which was the user agreement workflow, and defer the technical issues over where to store the agreement status until they could discuss the issue more.

Moral of the story

When discussing a story, if there is contention about how part of it is done, it is sometimes possible to split the story so that the understood part is separated from the not understood part, allowing progress to be made. In this case, we knew how to write the workflow, but not how to prevent the user from seeing the agreement each time. We split the story at that particular edge, which allowed the team to build something useful, and to defer what they didn’t know yet until they knew more about it later.

— bab

15 thoughts to “A Story Splitting Story”

  1. No offense but why is the story done from the perspective of the software user role when there is no user value in a license agreement? Seems to me it should read something like

    "As the legal department, i want every user to agree to our terms & conditions so we’re protected from suits"

    to me this makes the intent and intent much more clear.

  2. Hi, James,

    I can certainly see your argument and would have no problems doing it that way. OTOH, there is value in *agreeing* to the license agreement, or else you can’t get to the rest of your content.

    The main point of the post, though, is that it is 99.99% of the time possible to split a story into multiple parts, and by doing that, you can implement a piece of functionality that someone cares about, and defer that piece of the larger story that is difficult to do right now.

    So, you can something, instead of nothing.

    But I get your point about the role – I can see it from your point of view completely.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.