What is story slicing in agile?

Should we break this story down further?

If you are a member of an agile team, you surely know that product backlog is a major artifact and the quality of your product backlog is a key success factor. Well, how can you ensure that your backlog is refined and helping you to deliver frequent releases to optimize the value to your stakeholders and users? The answer is, “slice your user stories”!

Slicing the user stories means, you have broken down the requirements to smaller, manageable functional units that will deliver value to users, you have an improved workflow that will produced progressive results, help you mitigate the risk of failing to deliver the commitments. In this guide, let me help you to understand why and how you can slice your user stories!

What is a User Story?

A user story is the smallest unit of work in an agile team. It’s an end goal, user experience expressed from user’s perspective. It’s a way of thinking the user journey in defining the requirements.

Why we use a user story is to articulate how a piece of work will deliver a particular value back to the customers or users who can be external customers or internal customers within your organization who wants you to deliver value to them

Every user story may have the following three key elements:

A) Card: Represents the user story details including the functionality, user scenarios, business rules etc. Try to reach just enough details! If you have just enough details to move the story from "To Do" state to "Done", your story is refined enough.

B) Acceptance Criteria: This is critical. The acceptance Criteria is hugely overlooked by the agile teams(that struggle in delivering results and achieving sustainable pace and quality). Acceptance criteria defines the functionality or the user expectation to consider the implementation is accepted. Be critical, reach a-steady Acceptance Criteria.

C) Conversation: It's an ongoing discussion between customers and developers to figure out the most valuable business rules and user journey! It's not a sealed requirement, and therefore, you must ensure you have an ongoing discussion to refine the user experience, and deliver the optimal value to your customers!

Why should I slice a user story further?

Slicing allows you to deliver meaningful value to users

Vertical Slicing allows you to cut across multiple architectural layers to deliver meaningful experience/value to your users. It’s very different to the traditional approach of trying to deliver the UI only approach which doesn’t deliver real value to users.

Story = vertical, testable, user valuable.

Slicing means making thinner stories (but still vertical)

Ask yourself, how big are our stories? tasks? commits? Your answers will indicate how mature you are in your agile journey in delivering continuous value to your stakeholders. The more time you take to deliver a single story takes you away from agility.

Here are some guidelines around the ideal target sizing: Story = a few days. Task = a few hours. Commit = several times per hour.

Why split stories? Out of many possible reasons, some important reasons why you must split your user stories are:

Learn faster. Deliver more often. Happier stakeholders. More in-sync with other people & teams. Better prioritisation. Better product earlier. More business options. Less risk (less time “underwater”). Sense of velocity. Easier planning.

Higher Continuous Value to Your Customers!

As you see in the figure on the left, value curves for waterfall, big stories, and small stories shows you that having smaller stories delivers much higher accumulated, continuous value compared to bigger stories. In waterfall approach, we have bigger requirements that we try to deliver at once and that results a longer waiting time. The users do not see any value for months. By slicing down your stories much smaller size, it ensures that you are able to deliver value much frequently. This means, your customers see a greater progress in terms of delivering the value towards the end goals.

Once you realize that “we can’t split this story anymore!”, feel free to stop there!

How to Split User Stories?

Let me share some useful strategies that will be extremely useful you to break down large stories into manageable chucks of work.

01. INVEST

Independent: If user stories are independent, anyone can be picked and delivered in isolation. For large systems, this is tough — but, minimize the dependencies, identify, prioritize for a better backlog.

Negotiable: Leaving room for give and take and decide the details when you have more context. High priorities stories should be more precisely defined. Low priority stories should have more play

Valuable: The user story must have value to the user and to the business. Something meaningful is useful than unfinished, in progress work.

Estimatable: If you can’t estimate it, it is either too large, too vague, too risky, or some combination thereof. Solution includes adding acceptance criteria, splitting the story, or better defining it.

Testable: You need clarity on the story specific done criteria. Solutions include adding acceptance criteria or better defining the story

02. Think MVP

Agile emphasizes on Just Enough Designing (EDUF) before developing to ensure continuous, faster value delivery which is supported by Minimally Viable Products(MVP). We prioritize the must develop, survivors first and defer the features that can wait. This allows much faster value delivery ensuring we can reach the market and therefore, our customers with useful, meaningful products and features at a high pace.

When you slice your user stories, the same concept, MVP applies. Think of the smallest, minimally viable user stories that can deliver some meaningful experience to the users. As an example, if you are developing a login feature, what is the minimally viable experience? For me, it should have the most basic UI, the most simplistic logic built and the simplest form of output. So, you have covered all what it needs to work and make some meaning to the users.

In this approach, we critically ask the question, “Should we try to develop the most perfect product or feature at first” Or “Shall we just develop the bare minimal feature that can be used by the users?”

03. Breaking down the stories by Acceptance Criteria

Every user story must have an acceptance criterion that defines the business rules for the given user requirement. These business rules could be explicit or implicit rules. By studying these business rules, we are able to breakdown the stories into much smaller stories. You may prioritize these rules to ensure, you have a progressive approach.

04. Break down by Happy/Unhappy Path

Every User story has a happy path and an unhappy path! Usually, our test scenarios are written to focus on happy and unhappy paths. The same way, when you break down the stories, focus on the happy path first and then unhappy path. This will make our development and delivery faster.

05. Breaking down by test scenarios / test cases.

In this approach, we may focus on the acceptance criteria or in other words, functionality. Ask yourself, what’s the smallest testable functionality or the use case and how could you test it? Usually, the smallest user scenario testable is the smallest value that can be delivered to your users.

06. Breaking down by user personas.

User stories often involve more than one user group. These user groups may use your feature in their own way! Are you a freemium user or a paid user? are you an Apple user or a Windows user? are you using Chrome or IE 9? etc. By considering the various personas applicable, you can certainly break the functionality down in smaller chunks.

07. Quality Attributes

Quality is inevitable in product development and therefore, you must surely pay a lot of attention in ensuring the expected quality standards are achieved. Look into the quality attributes that you may want to focus, and you can use these attributes to breakdown your stories. You may find the compressive list of Quality Attributes here.

Bringing It All Together

Being agile means being able to deliver continuous value in shorter intervals. Agile teams must focus on incremental, progressive value delivered day in day out. This way, your customers will realize the incremental value towards the total value proposition expected. User Story slicing is a critical success factor in that context and how well you manage to break down large stores to smaller ones will ensure that you have an incremental value realized hourly, daily and weekly towards your big product goals and initiatives.

References

http://alistair.cockburn.us/Elephant+Carpaccio+exercise

How do you slice stories in agile?

How to do story slicing?

What is value slicing in agile?

What is story splitting in agile?