8

I've been reading various techniques for splitting large user stories in helpful ways, such as by user workflow through the system etc. What I'm struggling with is how to word these smaller stories if all they achieve is facilitating the next step in the process and not delivering the application's main benefit to the user.

For example, if my new system is split down into 3 smaller stories along the lines of;

  1. Create a new account online

  2. Create certain entities against my new online account

  3. Have my mobile device query these entities against my account and act on them

The system only really provides useful functionality to the end user when all stories are complete. So if following the traditional "As a [User] I would like [Functionality] so I can [Benefit]" The benefit of the first and second story is simply facilitating subsequent stories and not really providing the user with the main piece of functionality (the epic). Is this the correct way to do this?

Improve this question

2 Answers 2

Reset to default
6

You have three stories here which have to be done (probably in a sequence) to achieve a goal, being able to query against the entities from a mobile device is a feature which will deliver a business goal, it does not appear to be the business goal itself IMHO.

Here's my suggestion, phrase the business goal that your epic has to achieve and define stories like so

As a user I would like to register myself on the system so I can [business goal]

As a registered user I would like to create entities in my account so I can [business goal]

As a registered user with account entities I would like to act on queries against my entities from a mobile device so I can [business goal]

Improve this answer
2
  • An interesting question with an interesting answer. +1 for both. As a side question: what to do if, say, only two of the above user stories can fit into a sprint? I mean, at the end of the sprint you are not adding any tangible business value to the product: the completed feature (and business value) will only be there in a future sprint. Is this OK?
    – Giorgio
    Jun 1, 2013 at 9:54
  • 1
    Good question Giorgio. I'd argue that as long as you manage expectations to the business correctly, you are in fact still adding value to the business by only delivering a subset of functionality in the first sprint. The value comes from getting functionality in front of users who can then provide feedback for future development.
    – smstanton
    Jun 12, 2013 at 19:25
0

The best way then would be to treat it as an epic, and scope in stories in sprints thereafter. My answer uses the same approach (stories as part of an epic).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.