Who writes user stories and what would you advise them to write in those stories?
Welcome to part 17 in our scrum master interview questions series where John McFadyen answers common questions asked of scrum masters in interviews and client engagements.
Anybody can write a user story.
Some people think this is exclusively the role of a product owner, but that isn’t true or useful. It isn’t a single person’s role or responsibility to write user stories.
The person who writes the user story is the person best positioned to identify the need and articulate those requirements for the scrum team or developers.
That might be the product owner but it’s equally possible for that person to be a developer, a business analyst, a product stakeholder, or even a customer.
My advice is that you invite them all into the process.
Capture as many opportunities as you can
The people we work with are generally intelligent, passionate about the work, and want to contribute effectively.
Allow people who have a great deal of knowledge or insight into the product requirements to contribute to the design and writing of user stories.
The developers are interested in creating the most valuable product or solving the most compelling problem and having as much insight and information about the requirement or need empowers them to do exactly that.
Having that kind of insight and information allows the product owner to work out whether that specific backlog item helps advance the product toward its goal or vision, and make decisions about the priority of that item, relative to other items in the product backlog.
Capturing as many valuable ideas as possible is great for the scrum team, the customers, and the organization so invite as many people to contribute their ideas as possible.
Backlog refinement
Don’t limit what is added to the backlog or who is able to contribute to the backlog because your product owner and developers are going to evaluate each item as part of their backlog refinement.
This is where items are evaluated and decisions about that item’s readiness or value to the customer are made. If something isn’t clear about the item, the product owner or developers will have a quick conversation with the user story author to understand the problem or requirements better.
There are several formulae for writing user stories, and some of them are great, but ultimately you want the user story to inform a conversation that helps developers understand what the most valuable outcome for that user story would be.
Ultimately, the developers are going to make a decision around whether the item contributes value to the organization and customer, and is worth pursuing in more detail, or whether it is a nice idea but doesn’t contribute value at this moment in time.
So, backlog refinement will ensure that the team are working on the most valuable user stories and provide the refinement necessary for each backlog item.
What should we write in user stories
You have probably come across several formulae and templates for writing user stories, and if those work for you that’s great, but I wouldn’t get caught up in writing the perfect formula-driven user story.
The traditional user story format captures:
- Who wants the item?
- What do they want?
- Why do they want or need it?
How you write that down doesn’t matter.
When I coach product owners, I advise them to write the first thing that comes to mind about the item. Don’t worry about a special format. Don’t worry about identifying who, what, and why, because the purpose of the user story is to create a placeholder for a valuable conversation about the item.
It’s a ticket to take into a backlog refinement event and discuss with the team.
Something that allows you to articulate what is required, why that matters, and how value can best be created or captured for a customer. That conversation will also help the developers determine whether they have enough information to begin, or whether that item needs further refinement before it can be included in a sprint backlog.
Your primary goal is to help developers understand the item, the purpose of item, and how best to solve that problem or create that product. A user story is a prompt for the conversation that provides that level of insight and understanding, not a proxy for it.
So, it doesn’t matter what is written down in that first instance because the item is going to be discussed, refined, and potentially even evolve based on the conversation about that item.
If the user story articulates the purpose of the item and how it creates or captures value for the customer, you have a valuable user story.
In my experience, if you are still writing a user story after 2 minutes of starting, you are likely overthinking it and should start from scratch.
About John McFadyen
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster