Everyone owns the story, here is why
From the title of this blog post, you might be confused as to what I mean by 'All team members in the team, own user stories.' Before some of you write me an angry email, I want to clarify that I did not say 'All team members should write user stories.' I know this probably works for specific teams, but in my experience, it is best if the product owner or business analyst writes the user story.
The narrative of a user story needs to be clearly defined and should come from someone who knows what the end-user needs and what the eventual business benefit is. We need a clearly defined person(usually a product owner) who has the last say in the end goal of the story. We do not want ambiguity here.
That said, a user story isn't a requirement document or spec, set in stone. A user story is a conversation—a conversation between a product owner, the developers, the scrum master, and the testers.
Let me give you an example while working as a business analyst on a team once. I had written a story for some changes to a form. Now we have spoken about the story in the sprint planning meeting. We also had a clearly defined definition of done for each story. The developer moved the story to 'Ready for validation' on our scrum wall. While I checked the story, I noticed the developer had not added any validations to any of the form items.
When I spoke to the developer(who had moved on to another story), she said that validations were not mentioned in the story, so she didn't add them.
Our team member's stand was that the story was "done" because I neglected to add 'explicitly' the validation requirement for each form item. Since I was the owner of the story, it was my responsibility to get the requirements right.
Now I could argue with her that the definition of done for all stories includes a point that 'All form items must have validations.' I didn't do that though, because to me the problem was much bigger. It was that my team member here could consult with other members of the team, or had a conversation with me about this before submitting the story. Instead, she chose to treat the story as a requirement document, set in stone and worked independently instead of collaborating.
Here is what I think:
A product owner and business analyst do own the product backlog and do decide what stories are in the sprint, but the user stories are owned by an entire team, collectively, and should be written by all team members. Every team member has something to add to a user story.
So how did I get this team to start owning stories collectively?
I started by creating a user story template. This is the template we came up with as a team of what each user story should have:
Narrative - Written by the PO/PM
Clearly defined acceptance criteria in a tabular format.
Dependency on any other story(hopefully this was rare)
List of tech tasks involved with the story
Test data for the story
Images of designs and wireframes
Test cases - To be added by the QA.
Any open questions(known unknowns)
Now all of the above may seem like a lot, but this made sense for us.
Once we had the templates defined, we then moved to have team members write parts of the story.
So the acceptance criteria were usually written by me(business analyst) in collaboration with a tester and a developer on my team.
The developers wrote the tech tasks part of the story during the sprint planning meeting or at story kick-off(more on this later).
The developers added the test data for the story before submitting the story for testing.
The testers would add links to test cases for each acceptance criteria.
In this manner, we ensured that everyone was actively participating in the writing of the story.
Next, we implemented the story kick-off. This is simply a five-minute conversation a developer has with her/his team members when they start to work on a story.
So, some of us(usually me and a tester) would move on to our developer's desk(or get on a Zoom call with them) to go through the story together. We would run through the acceptance criteria to make sure that those still make sense. If we need to change anything in the story, what test data we need to create, etc.
This completely changed how our team members treated a story(a conversation instead of a document).
I hope you have found this post useful and can identify these patterns in your team as well. Please let me know if there are any questions here.