In the world of agile, requirements come in the form of user stories and it is important to understand that the details contained in the stories are needed to absolute clarity for anyone who is going to be working to get this stories done.
Consequently, here are several practices which can be adapted to organizations who are agile.
User stories
- Product owner (PO) and business analyst (BA) must collaborate closely with business stakeholders (such as customers and internal business units). The collaboration meant here must be two way negotiation and cannot be a top down, do or die approach.
Many times I have seen this in organizations that claim to want to be agile but its teams fail to comprehend the approach. What this means is that the agile product team has the right to question the user story motives and benefits to the product. This can come in the form of asking whether the features requested are to benefit certain segment of users or all users and business value / proposition that it brings to the organization. - Try to use an agreed template with the team on user stories such as the description, acceptance criteria and definition of done (DoD). Have a workshop with the team if needed to define and agree.
To illustrate and provide sample as below,
a) Description : Why ? Why why … This can be written down from the requestor / user’s perspective such as “As a [user], I want [feature] so that [benefit]” format.
b) Acceptance criteria : Define clearly the requirements such as putting the details as below
– What is the end to end flow for the story to be successful
– What maybe the negative scenarios that can be considered as stretch targets
– How it can be illustrated (either in a diagram or mockups)
– At which point this story is required in the product to work i.e. during login etc ?
– What can be tested so that developers and QA team can take this into consideration in their respective testing. - Small and independent : Some stories can be long and detailed. In such cases, then it is prudent to check if the complexity of the story is getting too high and to break it down into further stories.
Another scenario which may need to split into stories besides the complexity is whether any analysis is required before the story development can be done i.e. to understand further the feasibility and applicability. - Clear and SMART acceptance criteria : Outline the specific conditions that must be met in order for the story to be considered Done.
- Utilize visual aids : Diagrams, charts, screenshots, mockups, story maps, user personas help stakeholders and the team to understand further the context and value of each user story.
- Prioritize stories : Stories that are in the sprint and sometimes new stories added mid sprint must always be prioritized according to business value and complexity. This is to ensure the team is working on the most critically valuable and impactful stories first.
- Continuous refinement of the sprint and backlog : By doing a regular review and continuously reviewing the requirements, the above step 6 can be done easily to ensure the current sprint reflects the current priorities and needs of the business.
Often times, if there is any technical changes required on the product, there will be minimal documentation involved. However, it is always preferable to have some of technical notes recorded so as to aid the understanding of the work that was done. Below are some ways how this can be incorporated into user stories :
- Through acceptance criteria: One way to include technical details in user stories is through the acceptance criteria, which outline the specific conditions that must be met in order for a user story to be considered complete. The acceptance criteria can include technical details, such as performance requirements or security considerations.
- Through technical specifications: Technical specifications or design documents can provide more detailed information about the technical requirements and constraints of a user story. These documents can be referenced in the user story or linked as supporting documentation.
- Through collaboration with technical team members: Involving technical team members in the process of defining user stories can also help to ensure that the technical details are properly considered. Technical team members can provide input on the technical requirements and constraints of a user story and can help to clarify any technical details that may be unclear to non-technical stakeholders.
Overall, it is important to ensure that the development team has a clear understanding of the technical requirements and constraints that need to be considered when implementing a user story. This can be done through the acceptance criteria, technical specifications, or by involving technical team members in the process of defining user stories.
Disclaimer: What I am sharing is purely from my point of view and experience working with various teams as a scrum master. It does not reflect anyone else’s opinion or endorses a framework.
What I present in my posts doesn’t necessarily mean that it is applicable to your work, organization and culture but I am glad if it aids you in your agile journey.
Sincerely and with many thanks for reading my articles, Jason.
