How to break down an 8 point story into smaller stories in Scrum?

Question

My team and I are struggling with breaking down a user story that we have estimated to be 8 points.

The user story is :

"A user can sign up to the app using a registration form so that he is granted access"

The reason why we estimated 8 points is that there are many acceptance tests involved.

I am trying to follow the INVEST model which suggests that stories should be small in order to fit in a Sprint. I can't figure out how to divide this "sign up" story into smaller stories that have value to users. Any suggestions?

Answer 1

I would walk the team through the Story splitting flowchart. Often someone has an idea how to split it, utilising the full team to split is often better than just trying to split it by yourself. Split during the planning or refinement sessions.

An split here could be something like:

• Login with manual user creation, value is that you can test with real users. (We have some applications where we never built the registration form, user management is done by email. I like that in splits, something you can not built.)
• Registration form, value is that the users can pre register.
• User management to assign access.

The idea is to get feedback, from users, but also feasibility learnings, e.g. can the team built it. I think the suggest splits here will surely get user feedback and or learnings.

If an 8 is less than 33% of your sprint, maybe don't worry to much about it. Sure 1/6 or smaller stories is ideal, but a 1/3 sized story once in a while is not to bad. Just make sure it is your first story of the sprint, so that your not left with a half finished story at the end of the sprint.

One last note, don't prematurely try to split, wait as long as possible. Splitting stories you might never going to pick up is a major waste.

Answer 2

Generally we try to avoid implementation details in a user story, so instead of

A user can sign up to the app using a registration form so that he is granted access

I would suggest your original story is:

As a user I would like to sign up to the application so that I can get access

With something like registration I would often break it down based on bare essentials and nice-to-haves.

For example:

As a user I want to sign up to the application so that I can get access

The basic story, that is a bare essentials sign up, maybe just capturing their name.

As a user I want the system to store my details so I don't have to re-enter them

A building block story that means we capture more of the user's details during registration.

As a user I want to have my data entry validated so that I don't accidentally use incorrect values

Use this one to add in validation, like checking post codes, etc.

As a user I want to be sure my password is difficult to crack so that my account is safe

Use this one to add in password difficulty checks.

...and so on.

You will often find that acceptance criteria can be turned in to smaller stories if you think of the value they provide from the point of view of the user.

Answer 3

There are many ways to break down user stories, but since you mentioned a lot of acceptance tests, my first guess would be to break apart the acceptance criteria in to separately deliverable segments. For example, do you have address validation in your acceptance criteria? That can be its own story:

As an app admit, I want the registration process to validate addresses to reduce the number of fraudulent account requests.

I'd also look to see what the minimum information from the form necessary to register is. It always raises a bit of a red flag for me when a form or screen is provided ahead of time. Usually, this means we're grouping a lot of related functionality into one backlog item because we've anchored on that artifact. It's possible that you could start with:

"As a new customer, I can register to use the app so that I can access locked features"

And this might ask for a username, password, and email. Then:

"As a new customer, I can include my full name in the registration process so that I don't have to go to another screen and add it later."

Apart from breaking down the story further, it'll force the PO and team to really understand why a user would want to have that feature. I rewrote the so-that for the last one 3 times trying to figure out why the user would actually want to provide that info at registration.

Answer 4

As mentioned in a comment, I'd need more details what makes this so difficult - this would give us ideas where to split. But apart from that, there is one way: separate the presentation from the backend operation. I.e., if you cannot complete this task in a sprint, then implement the backend first - so a user could, in theory, log in using a simple POST request; don't implement any GUI, no detailed error messages, etc.

Concentrate on making that API call secure as it should be, with features like enforcing HTTPS, storing/checking passwords in a safe manner (i.e., using a good hash, not plaintext), delivering your cookies in a good way, and so on. Decide what kind of session management you want to do (server-side in a DB, or just client-side in a sufficiently encrypted cookie). If you cannot manage the more complicated version in your sprint, then decide to do the easier one instead, and come back to it later.

Do not ship a version that misses essential security features. If you cannot even do that in one sprint, then it will be hard to find anything to improve, and you will have to take a good, hard look at your sprint length...

In the next sprint, add the GUI part; from that point onward you can more easily deliver only small increments. For example, in the first login GUI release, you may only implement the "positive" path, and skip all fluff regarding error feedback. There might only be generic error messages in case of trouble (or, even, no error messages, just a redirect to the empty form if you so wish).