_edited_edited.png)
Nothing is particularly hard if you divide it into small jobs
-- Henry Ford
Within the Agile framework, work completed is often based on User stories. User story describes a software feature from the perspective of the end user. It is a chunk of functionality that is of value to the customer. User story as an idea was borrowed from Xtreme programming which introduced these small packets of information pointers to document and communicate requirements, priorities, acceptance criteria and needs of the user. Just as pointers user stories hold the address to a series of conversations about the desired functionality. A user story is a story behind “WHY” a user need something. We record all these “WHY” s in a backlog called Product backlog.
In a user story, we describe who is the story for (role), what functionality is going to be delivered and what is the value from it. It is all about conveying the value of what’s going to be created. When user stories are created from an epic which is a larger story, they should be broken into smaller workable pieces which allows the team to get high quality value and feedback at frequent intervals.
The three C’s of a User story
Every user story has 3 key elements. The three C’s stand for Card, Conversation and Confirmation
Card – Represents the user story details including the functionality, user scenarios, business rules etc. If the user story has enough details to move the story from ‘To Do” to “Done”, then it is refined enough. This is the planning and estimation phase.
Conversation – It is an ongoing discussion between customers and developers to figure out the most valuable business rules and user journey. The conversation is where the real value of the story lies and the Card should be adjusted to reflect the current shared understanding of this conversation.
Confirmation – Specific acceptance criteria that is different from the current ‘Definition of Done’ should be established for individual stories. Team should work towards an agreement on what to build. Record that agreement as a set of confirmation tests and all associated acceptance tests should be in a passing state.
Attributes of an effective User story
User story template
The title of a user story follows a very definite formula:
AS <role>
I WANT <objective>
FOR <motivation>
The user history defines a functionality, since in a sentence it must make clear WHO (role) performs an ACTION (objective) to satisfy a NEED (motivation).
Role – The user should be an actual human who interacts with the system.
Objective – The behavior of the system should be written as an action.
Motivation – The need should be real world based that is non-functional or external to the system
Some example user stories:
AS a user I WANT to be able to search for transactions TO be able to see unnecessary expenses in my account in a period
AS a job seeker I CAN limit who views my resume SO THAT I have privacy
The title of a user story must map a functionality of our product or software. It must be remembered that the title of a user story must map a single functionality of our product or software.
Description of a User story
The description of a user story helps to give context to that story. The description may contain a small explanation of user flows, some use case, extreme cases and in general any explanation that helps to better understand the title. The description should not be a bible, and a picture is worth a thousand words, elements such as links to design pages are welcome, as well as screenshots that help clarify what is being expressed.
A good description of a User Story will contain these elements if available:
Context: Provide application and use context to the developer and user, to improve the understanding of the user story title.
Links to the mockups or design: They are a great help to understand how the functionality in the user story is to be mapped in the application.
Constraints: Things that all the actors involved in the user story must take into account (navigation constraints, design constraints, use cases or business flow cases).
INVEST
User stories are made to encourage conversation between people that have some ideas about the product and the people that will build the product. A good user story meets the INVEST criteria. INVEST are the guidelines for quickly evaluating the quality of user stories. It’s an acronym which means
Independent – A User story should be independent of other user stories; it means they can be developed in any order. As much as possible, developers need to make sure that stories are not interdependent as this might lead to prioritization and planning problems. Independent is different from logical order of developing things.
Negotiable – A User story needs to be brief; its purpose is to encourage negotiation and scope between developers and customer. It’s more like a living documentation which can change when something new is discovered
Valuable – A User story should provide value to the customer or the user. Another reason to have a value statement is that value represents why we are building a certain feature. Presenting the team with the Why (value) and not just the What (feature) might trigger different ideas of alternate features that are easier or faster to develop and yet achieve the same goal and deliver the same business value
Estimable - Developers need to be able to estimate a story. It should be written in such a way that the developers can understand it and have an idea of how to implement it. Key factors for estimation are properly sized stories as well as domain knowledge and technical experience.
Small - The stories should be small. They must fit within a sprint. Small pieces of work are easier to estimate and less risky than large ones. Small stories provide focus for the team and gives members the flexibility to adjust and adapt to changes.
Testable - Stories should be testable in order to help determine completeness. Every story should have a specific acceptance criteria and the Definition of Done generic for all the stories. This helps the right product to be delivered in the right way. These criteria can be measured and automated during testing.
Why do we need to split the User stories?
Before a user story is ready to be scheduled for implementation in an upcoming iteration, it should be “small enough”, the usual rule of thumb being a story that can be completed within the iteration. However, many user stories start out larger than that. Splitting consists of breaking up one user story into smaller ones, while preserving the property that each user story separately has measurable value. Let us look at some benefits of user story slicing.
Small user stories are easier to understand - Smaller the story, the less complicated it is. Large user stories need further refinement to break them down into more manageable pieces. Key indicators that a user story is too large are if the estimate is greater than the Sprint duration, or if the estimate is greater than the remaining time left within the Sprint based on what has already been added to the Sprint. The team gains better insight into how much time is really required to implement its functionality.
Helps in identifying waste – If the team splits a larger user story appropriately it may be found that some of the smaller user stories are not essential to delivering the expected outcome. Some broken scenarios may not be relevant or may not happen. In such cases the team can save time by not addressing those scenarios in the development work.
Provides faster feedback loop – Smaller user stories could be delivered sooner which means the team can the feedback faster as well and if the team took a wrong path, they were wrong, for less time.
Reduced Risk - Stories that are complex and risky are candidates for further refinement using spikes to gain a better understanding of the problem and discover ways of breaking up the story into less complex parts. A key indicator that a user story is complex is if the team is having difficulty providing an estimate.
How to split User stories
When splitting user stories, we should always split them vertically as if we are slicing a piece of cake. The whole cake is a cake and each vertical slice is a piece of cake with all its layers. A horizontal slice might just have the icing, or maybe just the filling, or just the crust and does not make for a very tasty cake. Similarly, stories should represent some level of end-to-end functionality. Splitting stories into smaller stories like design, create data model, code the front end, code the middle tier, code the back end, integrate, test, will result in no value delivered until all stories are completed. It is always better to deliver a cohesive subset of all layers of a feature than delivering all of one layer as a standalone. This approach reduces overall risk by continuously integrating different parts and ensuring constant delivery of customer value.
Strategies for Splitting User Stories
When it comes to splitting, the rule of thumb is to split a user story so that it can be completed within a single sprint. We should split an epic to a user story but not to a point to where it becomes a task that is not valuable to the end user.
Below are some of the common ways of splitting user stories
Workflow steps - This involves splitting the user story into individual workload steps where each step can be a separate user story.
Acceptance criteria – Every user story must have an acceptance criteria that defines the business rules for a given requirement. These rules may be prioritized to ensure, there is a progressive approach.
Happy/Unhappy path – Every user story has a happy path and an unhappy path. When the stories are broken down, focus on the happy path first and then the unhappy one. This will facilitate a faster development and delivery.
Zero/One/Many – There might be a case that even after splitting a user story, you find that it is still big, in this case we can use zero/one/many technique.
User roles – If a user story involves or interacts with different user roles or persona then the user story can be certainly split for each user role interaction.
Business rules – This pattern is used for stories that involve a number of explicit or implicit business rules.
SPIDR approach for splitting user stories
Another interesting and helpful method for splitting user stories into more lightweight stories more easily and effectively. Agile coach and co-founder of the Scrum Alliance, Mike Cohn, noted that "almost every story can be split with one of five techniques". He summarizes these five techniques under the acronym "SPIDR".
Spikes - is a term used in agile software development. Spikes are small, prototypical implementations of a functionality that is typically used for the evaluation and feasibility of new technologies. This is used as a last option for splitting a user story.
Paths – If there are several possible alternative paths in a user story, one option is to create separate user stories from some of these paths. It is not absolutely necessary to write a story for each individual path, just where it makes sense.
Interfaces - In this context can for example be different devices or device types, such as smartphones powered by iOS or Android. User stories can also be split in terms of this diversity. All these interface combinations can be different stories.
Data - Another technique for splitting user stories can be used when the initial stories refer only to a sub-range of the relevant data.
Rules - Business rules or technological standards can be another splitting factor. Consider relaxing these rules in an initial story and add support for additional rules in the subsequent stories.
And that brings us to the end of how to create effective user stories and techniques of slicing the user stories in Agile environment. Hope you found my blog interesting and helpful. Please do give a thumbs up if you like it and do not forget to post your valuable feedback.