How to write user stories for better product management
Greetings to the product multitude. One of the critical aspects of product management and ownership is to write user stories. As we all know, user stories provide context and clarity to the development team. It answers the key questions - "who", "what", and "why". A PM/PO can deliver maximised value by writing better user stories.
Great user stories come from continuously interacting with the stakeholders. Scrum principles define three necessary stakeholders for the product owner to interact with:
1. The Users - The end users who use the product.
2. External Customers - The people responsible for paying to build and use the product.
3. Internal Customer - The people responsible for making the funding decisions for the product development effort.
A user story is an essential sub-artefact in the primary artefact - product backlog. In addition, the user story helps a scrum team achieve transparency.
We write this post from our experience and the iterations our user story template has gone through with the intent to help all the PM/POs out there.
Empathy
User Story Composition:
1. Simple Outline
The standard outline for a user story is simply - As a [user persona], I want to [task definition] so that I can [goal definition]. For example, for our homegrown product that builds Chatbots for small business products - ObiiBot, we wrote -"As an owner of a small business, I want to build a chatbot without technical help so that I can create a customer acquisition funnel."
2. Acceptance Criteria
A user story should include the terms and conditions of acceptance. Acceptance criteria clarify the expected outcome and quality of the user story. This information is vital for the development team to understand achieving the desired goal. Acceptance Criteria Outline: Given that [Context], when [Action Statement], then [Expected outcome ]. For the above-mentioned user story outline, we wrote - "Given that the owner of a small business wants to set up a chatbot without technical help, When they signup, provide an interface to drag and drop conversation components.
3. Value Points (Priority)
A user story caries an attribute called "Value Points" - a value point is just a value measure of the user story. PM/PO adds the Value points in consultations with the stakeholders. Value points provide a critical understanding to the development team of the "value" user story delivers for the stakeholders. Value points are usually relative in nature. Teams use the Fibonacci series numbers (0,1,1,2,3,5,8,13,21,34,55...) or t-shirt sizes (S, M, L, XL, XXL..) to define the value points.
4. Story Points (Estimate)
A user story carries an attribute called "story points" - a story point is a relative measure of time and efforts defined by the development team to build the user story. Scrum principles don't vouch for exactness but instead believes that relative estimates are far more efficient. The story points provide PM/PO and stakeholders a realistic understanding of the time and effort required by the development team to build the user story. Like value points, teams use relative measures to define the story points. Teams use the Fibonacci series numbers (0,1,1,2,3,5,8,13,21,34,55...) or t-shirt sizes (S, M, L, XL, XXL..) to define the story points.
Relative Measure Vs Absolute Measure for Value and Story Points
We, as human beings, lack the exactness and precision required to provide absolute estimates. We all have experienced delays at some point in our lives. A project never gets done based on the initial estimate, even for highly efficient companies. There is always a point of digressing.
However, We are good at providing relative estimates. For example, there is a product 'X' which took ten weeks to develop, and there is a product 'y', which is twice the size of product 'X', relatively and realistically, it is safe to assume that Product 'Y' could be built-in twenty weeks.
Many scrum teams use relative measures to assess Value points and Story points for this precise reason. Relative estimations are far more accurate than absolute measurement.
