User Story(ies) for multi-step user sign-up

Question

I'm just starting to use Scrum with a new web project and I'm having some difficulties crafting my Product Backlog.

I have a initial user story along the lines of :

As a new user I want to sign-up in order to access the private section of the web portal

In the future web portal the creation of a new user account is systematically precedeed by a step-by-step questionnaire featuring 10-20 questions (mostly multiple choice). Once the questionnaire is completed the new user enters an email address and password and provided that these are valid, the user account is created and the new user redirected to a Home Page / Dashboard view.

My user story seems lacking in detail but I'm not sure how to split it up (nor whether this is appropriate)...

Any ideas/suggestions ?

Many Thanks

Answer 1

First off, I'd like to point out that I think you're going at the wrong angle with that story.

Have you ever wanted to sign up for anything? Wouldn't it be better to just be able to use the thing, without having to bother signing up or logging in? 'Why can't (Company X) just turn the private area public?'

First determine who the requester of this story really is. Or, alternately, change the request. For example, something like:

As a system administrator, I need to make sure we aren't vulnerable to...

or

As a user, I don't want other users able to see my personal information.

Note that these don't even have the how of sign-up and log-in built in. It could conceivably be accomplished through some other means. This is good, as the how of tasks should not be coupled to the what and why of stories.

Once you've properly identified a real business need, including who wants/needs it and why, then you should be in good standing.

After that, you can start adding the how into tasks under that story, but that has nothing to do with defining the story itself.

Answer 2

A good idea would be to think about the Acceptance Criteria for your user story. When writing those down, you would probably see huge numbers of them which give you hint on how to slice your user story.

For example "as a new user", what are the acceptance criteria for that? Any new user? users on their mobile phone? on tablets? can they call in and someone helps them over the phone? a new user to the private page or a new user with no information of him/her in your system.

Answer 3

The other answers covered pretty much everything, I just want to add a couple of things:

• Consider adding a "...so that..." clause at the end, as this might narrow down your scope in order to be more specific.
• Consider reviewing a cheat sheet as described here. If need be, consult the developers in your team to help you, or BAs around you, according to the business needs.

Answer 4

Engage Entire Team in Writing User Stories

In the future web portal the creation of a new user account is systematically precedeed by a step-by-step questionnaire featuring 10-20 questions (mostly multiple choice). Once the questionnaire is completed the new user enters an email address and password and provided that these are valid, the user account is created and the new user redirected to a Home Page / Dashboard view.

Repeat after me: "User stories are not specifications!" You are struggling because you're trying to create a detailed specification using the standard Connextra As a...I want...so that... format, but that's not how user stories are intended to be crafted or used.

While a user story should follow INVEST criteria, in this case the problem isn't so much making it more granular; it's in finding the right level of granularity to effectively create Sprint-sized chunks with the team. To do this, you need to do a couple of things:

1. Involve the team in creating the stories.

   As you discuss the stories and the possible implementation details with the rest of the team, you will discover how best to capture and decompose your epic. You may find you have one story or many, discover stories or dependencies you haven't considered in your role as Product Owner, and provide context to the team.

2. Ensure each story fits within a single Sprint.

   A single user story must fit within a single Sprint. If it's bigger than one Sprint, it's probably a theme or epic and should be decomposed. It can be smaller, but whether it's a big story or a set of small stories should make very little difference except to your level of risk.

   Smaller stories allow you to make progress even if the Sprint Goal isn't met, while a big story trades upfront planning and decomposition for just-in-time planning by the team within the Sprint. This can increase the risk undelivered stories or a failure to achieve the Sprint Goal, but not every story has to be less than 13 points of complexity.

3. Make sure each story is testable.

   Using test-first design, rather than overwrought specifications, is generally the best way to decompose work and to ensure it meets the team's Definition of Done. Doing this collaboratively is the most effective way to define the right tests.

You may find that you need to dedicate a Sprint to developing the contents of the Product Backlog and refining stories for the next one or two Sprint Planning meetings. That should be enough to prime the pump, and it's okay to allocate that to the project if necessary.

Consider making the following user story your top story in the backlog:

As a Scrum Team,
we want to collaboratively define the user stories for the login epic
so that we get the right level of granularity and create sufficient context.

This kind of story is equally acceptable for project initiation, "Sprint Zero," or Backlog Refinement. Once the whole team is actively discussing the epic or theme, the level of granularity needed should become self-evident.