Transitioning From Quality to Product Management — pt 3
In Agile, one of the most common approaches for capturing the user’s requirements is User Stories. They represent customer requirements in a card, leading to conversation and confirmation (Jeffries, 2001).
Let’s start by clarifying that anyone in an Agile team can write a user story. However, the product owner needs to make sure the user stories are actually necessary for the product and they have a prioritized backlog. To make sure this happens, the PO needs to communicate regularly with the team and they discuss the stories together. User stories should get written collaboratively during the product backlog grooming/refinement sessions.
A user story describes functionality that will be valuable to either a user or a purchaser of a system or software. They are generalized details of the user requirements of the system and what the client hopes to gain from this functionality. They don’t show much details and the requirements are added later on, once they are agreed upon by the team.
User stories are high-level and simple, written only long enough to include a brief description and acceptance criteria. The user stories are not only composed of a written description but also conversations about the story that serve to clarify the details of the story. They also contain tests and documents that help determine when the story is complete. Remember: user stories are not a full description of work to be done; their purpose is to encourage collaboration.
List of conditions that need to be met in order to accept a story as complete.
“What needs to be done”.
It is very important that before agreeing to work on a story, the team must clearly understand the acceptance criteria.
All the tests that form the ‘acceptance criteria’ for the user story. Each acceptance criteria can have one or more acceptance tests. They can be functional and non-functional.
“How they should be done”.
To create a great user story there are six attributes we can focus on:
Avoid introducing dependencies between stories because dependency leads to prioritization and planning problems, and harder estimation.
Stories are not written contracts, they are reminders to talk to the customer. They are short descriptions of functionality, the details of which are to be negotiated in a conversation between the customer and the development team.
- VALUABLE FOR USERS/CUSTOMERS
Stories should be written so that their value to users or customer is clear. To ensure each story is valuable to users/customers have the customer write the stories.
The larger the story, the harder it is to estimate it. Developers need to be able to estimate the size of the story or the amount of time it will take to turn a story into working code.
Size matters because if stories are too large or too small you cannot use them in planning. The user story is appropriately sized based on the team, its capabilities, and the technologies in use but also small enough to fit in a Sprint.
Successfully passing the story’s tests proves that it has been successfully implemented.
When blocked on how to shape a User Story, elaborating the structure of your user story by using mind maps is very helpful, for example:
The product owner is responsible for adding to the product backlog only useful features and providing the best return on investment, this way the User Stories get prioritized based on their value to the organization. During a Sprint planning meeting, the team decides which stories are being tackled for the next Sprint, forming the Sprint Backlog.
Definition of Ready
Definition of Ready (DoR) is an explicit and visible working agreement between the teams and the product owner on what readiness means for them. Basically a criteria that a user story must meet prior to being accepted into the upcoming Sprint. The team decides and can refuse to take an item into the Sprint if the DoR is not met.
Normally the DoR follows the format of a checklist based on the INVEST matrix and the user story including an acceptance criteria. User stories get reviewed during the product backlog grooming/refinement meetings.
Definition of Done
The team agrees on a list of criteria that must be met before a product increment (usually the acceptance criteria of the user stories) is considered “done”. Definition of Done (DoD) is critical for a team since verifying that the activities completed meet the DoD criteria will ensure that you are delivering features done, in terms of functionality and quality. The PO officially determines when the acceptance criteria is met and at this point the user stories are considered “accepted”.
When writing a user story keep in mind to think about your user, a clearly defined role. if there are multiple end-users you could consider making multiple stories. User Personas is a method that helps to scope out the range of users, it supports writing user stories from the user persona’s point of view. Its impact is discovering the right stories.
More about this topic → How to create a User Persona
Large user stories are actually Epics and they are further divided to form smaller stories. If a story doesn’t fit in an iteration, the story needs to split into two or more smaller stories.
Smaller as “small enough” stories are way better since they get implemented, delivered, and returning value more quickly. I am stressing this part because if a story is too small, it won’t provide a measurable business value. Eventually, you and your team will get better at splitting stories.
Benefits of breaking into small manageable units of work are:
- Estimation and tracking are easier.
- Small pieces of work promote ownership and accountability by the team
- The tasks are more doable
- It is effortless to uncover key risks early on
More about this topic → Patterns for Splitting User Stories
Estimation is hard in the beginning. What is the right size of a story? There is no standardized or universal size for a user story, it always depends on your team, their skills, the technology in use, and their level of domain knowledge. Same as with splitting, when your team has a cadence, this will be easier and more accurate. The decision on which technique to use to point stories relies on you and your team.
More about this topic → All about story points & Agile estimation series
Ok but, why User Stories?
- It is an easy-to-understand concept.
- Right size for planning.
- Work for iterative development.
- Emphasize verbal rather than written communication.
- A placeholder for further discussions.
- Reduce waste since nothing is done with the user story until it is prioritized by the customer.
Finally, some things to consider:
- The difference between a user story and a traditional requirement is the level of detail.
- Avoid the how trap. Acceptance Criteria states intent but is not a solution.
- Do not write User Stories that require the development of other features.
- Acceptance criteria need to have a standard of measurement used to gauge the progress of product development.
- Effective User Stories should not exist without tight collaboration with the user and without them understanding what the requirement will supply.
- Do not feel pushed to use User Stories, if this format doesn’t work for you there are other ways to do it.
- Take a story writing workshop-helpful to figure out how to improve the product backlog and to fill it more effectively.
User Stories Applied: For Agile Software Development
Thoroughly reviewed and eagerly anticipated by the agile community, User Stories Applied offers a requirements process…
Scrum Guide 2020 Updates
This page provides a series of articles, blogs, videos and more that pertain to the 2020 version of the Scrum Guide…
Next steps in part IV…
The advice other awesome PM/POs gave to me.
Thanks for reading!
Clap 👏 — please show if you like this article so others can find it.
Respond 💬 — please let me know if you have any suggestions or questions.