User story splitting techniques

Click to edit Master title style

User story splitting techniques

Ashutosh RaiAssumption:

Audience already aware of user stories

How to write a good user story.


Should I split this story?

Does it meet the INVEST Criteria (with exception of Small)?

No – refactor story first.

Can it be completed in this Sprint?

No – time to split!

Will this story consume most of the Team’s capacity?

Yes – better to split than to be sorry…

Who all need to be involved?

Scrum Master for sure

Technical Lead if required

Some time teams decide this during refinement (grooming) session.


Agile manifesto principle

Do the simplest thing you could possibly do first and get it working end to end.

You have always got something to demonstrate, and a potentially shippable product.

To get there try some of these story splitting approaches……..

Simplicity --the art of maximising the amount of work not done is essential


Split by workflow

If user stories involve a workflow of some kind, the item can usually be broken up into

individual steps

What steps does a user perform?

Are all steps necessary (in current sprint only)?

Can steps be simplified (for next sprint)?

Improved understanding of the functionality

Does the story describe a workflow?


Split by operations

If a user story involves a number of default operations, such as Create, Read, Update,

Deleted (commonly abbreviated as CRUD), Configure, Maintain etc..

What all operation does the story required?

Are all operations necessary ( in next one sprint)?

Can operation be simplified (for next one sprint)?

Does the Story have multiple operations?


Split by user roles

User stories often involves a number of roles (or groups) that performs parts of that

functionality.

What all roles are involved in this story?

Do we need all these roles(in next one sprint)?

Can some roles be simplified (for next one sprint)?

Does the story associates multiple user types.


Split by business rules

In case a story involve a number of explicit or implicit business rules

What rules apply to the story?

Are all rules necessary (in next one sprint only)?

Can simpler rules suffice (in next upcoming one sprint)?

Helps in testing with all expected Scenarios

Does the story have multiple business rules?


Split by Acceptance criteria

This strategy is useful when it is hard to break down large user stories based on functionality

alone. In that case, it helps to ask how a piece of functionality is going to be tested. Which

scenarios have to be checked in order to know if the functionality works?

What all tests are used to verify the story?

What acceptance criteria applies?

Are all test scenarios necessary(for next one sprint only)?

Is it difficult to split the functionality alone?


Split by input options / platform

If story have to support various input options and/or platforms, like desktops, tablets,

mobile phones or touch screens.

Which all platforms are supported?

Are all platforms necessary (in next one sprint)?

Are some platform harder then other (for next one sprint only)?


Split by happy / unhappy flow

Functionality often involves a happy flow and one or more unhappy flows. The happy flow

describes how functionality behaves when everything goes well. If there a deviations,

exceptions or other problems, unhappy flows are invoked.

Unhappy flows describe exceptions. By identifying the various flows

What does the happy /unhappy flow look like?

Are all unhappy flows necessary (in one next sprint)?

Can unhappy flow be simplified(for next one sprint)?

Split by workflow


Questions?

Thank you Ashutosh Rai

User story splitting techniques

Career

Transcript of User story splitting techniques