A user story is a simplified description of a requirement that outlines what a user needs. It is an informal, natural language description of features of a software. In Agile terminologies, User Story is a tool in software development used to capture a description of a software feature from a user’s perspective, who desires the new capability, to achieve some benefit. There is a precise format for writing user stories, but I won’t be talking about it in this blog. Here, I’ll be talking about typical problems that business analysts and/or product owners face when it comes to managing user stories during development when user requirements change. So, let’s see some of the issues that people generally face for the unexpected and evolving requirements.
How can I Create Effective User Stories with Finer Details?
It is commonly observed that when certain features do not function as expected, the development team often complain that the user story lacked necessary details. It’s true that lack of necessary details in user stories lead to misunderstandings, incomplete implementations, and ultimately, features not functioning as expected. However, sometimes it is challenging for a business analyst or product owner to frame detailed user stories based on the requirements. Here, I would not make the common, vague statement that some people used to make that the user stories should be clear and detailed—since it is difficult to define what exactly clear and detailed means—I would rather like to offer some tips to help overcome these challenges, which are as follows:
- Ensure that one User Story represents only a unit piece of work for one kind of requirement. Do not mix different functionalities within the same User Story.
- Ensure that User Stories are self-contained without dependencies on other stories.
- Ensure that the following non-technical details are include in the user story: 1) Role to identify who the user is (e.g., customer, admin, visitor), 2) Action to describe what the user wants to do (e.g., receive notifications, make a payment), and 3) Benefit to explain why the user wants to perform the action (e.g., stay informed, save time). You can provide some reference link to some document, some ongoing discussions, or minutes of meeting, etc.
- Do not forget to add the Acceptance Criteria statement stating the condition or output on fulfilment of which, the User Story should be considered as ‘Done’.
If the above points are judiciously added to the User Story, we can safeguard against the complaint of missing details in the user story.
How to Convert Requirement into User Stories?
Transforming requirements into user stories is a key process in agile development. User stories should focus on what the user needs and why, without going into technical details on how it should be achieved. The following steps should be followed to convert requirements into user stories:
- After gathering the requirements from users, customers, or stakeholders, first create a high-level document that outlines all the functional and non-functional requirements that are identified so far, which can be updated as requirements evolves.
- Also, identify the different types of users who will use the application or system. Create user personas to represent the different user roles and their specific needs and goals. This helps to create user-centric stories later.
- And then comes the most important step—Break down the high-level requirements into smaller, manageable pieces in some written form for the ease of managing. You may use an excel sheet for listing all the ‘smaller pieces of requirements’, each identified as summarised details or using some quick headlines. But focus on the specific functionalities and features needed without repeating the details in the excel sheet.
- Determine priority of each requirement based on user needs, business value, and technical feasibility. Note that these priorities may get updated during the Grooming and Prioritisation sessions later when reviewing with the development team.
- For each of the ‘smaller pieces of requirements’ identified above, create a user story in the standard and known format, mentioning the Role, Action, and Benefit as already described in the earlier question. Sometimes, it may be required that more than one User Story is needed to represent a ‘smaller piece of requirement’.
- You can create the user stories directly in a project management tool like Jira, but make sure to link each new user story against the corresponding piece of requirement created earlier. This linking document or spreadsheet serves as your Requirement Traceability Matrix, which helps to identify and relate the requirements and also understand the historical context of the user story against the associated requirement.
That’s how I would suggest to create the user stories from the user’s requirements. Although too much documentation is not preferred in Agile but a pre-documentation of the requirements and then breaking down the high-level requirements into smaller ones always help.
How to Manage User Stories for Frequently Changing Requirements?
Well, change is always welcomed in Agile. In fact, Agile methodologies were developed to handle the situations of frequently changing requirements. One of the four main Agile principles encourage to respond to change over following a plan. So frequently changing requirements should not be a problem because it is certainly manageable with Agile practices, as mentioned below:
- Always use user story mapping to visualise the user journey and identify the requirements for the features or tasks. Define the acceptance criteria for each user story in such a way that it covers the identified requirements to ensure everyone understands what “done” looks like. Encourage collaboration among cross-functional teams to share understandings on the definition of done which helps in collective problem-solving.
- Prior to development, user stories should be updated for any changes in the requirements. But once the user story is in development with ‘in-progress’ or ‘completed’ status in a sprint, it should not be updated for any new change. Instead, a new user story should be created and prioritised for the new update maintaining the user story mapping. Unlike requirements document, user stories should not be considered as living documents.
- Occasionally, changes in requirement can be accommodated in the user stories that are in ‘in-progress’ if development team has room for accommodating the change in a sprint. In rare cases, critical updates in requirement can be incorporated in the user story even after development is ‘completed’ for the user story in question. In that situation the team need to take the user story for re-development as Rework. This is required if the update in the requirement is so important that it can’t be delayed and should go in the same release. The team should discuss and decide to accept the update as rework in the sprint.
- On top of the requirements, utilise the suitable agile framework—Scrum or Kanban—that suits for the specific project; Scrum for iterative development with dedicated sprints and Kanban for continuous development without sprint. For example, if the requirements evolve and change too frequently, or the release has flexible deadline, you may take the Kanban route, else the Scrum route. These frameworks are designed to handle the changing requirements effectively.
- If the Scrum route is followed, work in short iterations or sprints, allowing for regular reassessment and adjustment of user stories for requirements. Regularly review and refine the product backlog to ensure it reflects the latest priorities and requirements. Re-prioritize user stories as new information and changes arise to focus on the most valuable features.
- And most importantly, maintain open and frequent communication with stakeholders to understand their evolving needs and expectations. Conduct regular meetings such as daily stand-ups, sprint reviews, and retrospectives to keep everyone aligned and informed on progress, learnings, new developments, and any updates in the requirements.
I think if these basic rules and Agile principles are sincerely followed, we can manage user stories for frequently changing and evolving requirements.
Can we Consider User Stories as Documentation and Update as Living Document?
Some people consider user stories as another kind of documentation that can be updated as and when required, like we do in the living documents like BRD, PRD, FRD, etc. I think this approach is not fully correct. User story is not the appropriate location to put all detailed requirements in it, which makes the user story long, bulky and difficult to understand and maintain. Please consider the following points while dealing with the user stories:
- User stories are just high-level work units for the development team, which mainly focus on what you need to achieve as a user for some action. It contains acceptance criteria that validates if that work unit really adds the value as intended.
- User stories should be precise and concise as far as possible and should not be overloaded with too many unnecessary requirements. For detailed documentation with diagrams, workflow, finer requirements, etc., one can use documentation tools like Confluence, etc., and we can add a link as reference to that detailed documentation in the user story.
- Once development is completed, the user stories are closed and no longer used. For any change or update in the existing requirements, ideally new user stories should be created after first updating the requirement documentation. However, at times we need to update the ongoing user stories as already described in the above.
- If the changes are minor and directly related to an already developed user story, you can reopen the existing story and update it with the updated acceptance criteria to reflect the new requirements, ensuring that the criteria are clear, testable, and aligned with the updated needs. If the changes are substantial or introduce new functionality, it’s always better to create a new user story with fresh acceptance criteria based on the new requirements. This helps maintain clarity and keeps the development process organised.
- If the new users story created is related to any existing user story, we should link the two user stories. Additionally, we should add one liner note in the older user story stating that new update identified as detailed and to be worked in the (with link to the) new user story.
Hence, user stories are not living documents. Their lifespan ceases once the associated development is complete. After development is over user stories should not be updated. When a user story does not match the test cases for a developed piece of code, it can lead to several issues that need to be addressed. Test cases are designed to validate the acceptance criteria of a user story, but if they do not match, the code may fail during acceptance testing.
When should we Split a User Story into Two or More?
Splitting a user story is a common practice to manage work more effectively, especially when the story is too large, complex, or contains multiple independent features. Here are some practical scenarios we face, when we should consider splitting a user story:
- Too Large or Complex: If a user story is too big to be completed within a single sprint or sprint, it should be broken down into smaller, more manageable stories. In practical scenario, during story sizing for Agile estimation if a user story is marked with a story point of 13 or more, it is always better to split that story into smaller ones.
- Multiple Features or Actions: If the user story includes multiple distinct features or actions, each feature or action should be split into its own user story. That’s because if any requirement update comes for one feature or action, then the other feature or action should not be affected.
- Different User Roles: If the story involves different user roles with separate needs or actions, then always create separate stories for each role to keep things clear and focused.
- Different Acceptance Criteria: If a story has multiple sets of complex acceptance criteria that don’t naturally fit together, it’s better to split the story.
- Sequential or Dependent Steps: If the story includes sequential steps that must be done in a given order, when without completing a former step the later step can’t be implemented, then in that case each step can be split into its own user story.
- Independent Parts: If parts of the story can deliver independent value to the user, those should be split to allow for incremental delivery. That’s because in Agile a working software with some value should be is given preference. We should deliver any value as soon as possible, without waiting for other features that can be delivered in upcoming iterations.
By splitting the original story into smaller, focused stories, each one becomes more manageable and can be completed within a single iteration. This also allows for better prioritization and incremental delivery of value to the user.
If you have any query or suggestion, or if you want to point out any correction that I may have missed or overlooked, please let me know in the comment box below.