User stories open meaningful conversations. They help you plan and prioritize the features you want to build. And they keep you focused on what delivers value to your customers.
A question you might have come across many times is who should write user stories. Should the Product Owner and Developers collaborate?
One problem I have often encountered with collaboratively writing user stories is that many times, management thinks it’s a waste of time for Developers.
But let’s see what are the top 4 challenges Product Owners face when they write user stories by themselves.
1. Teams are not taking responsibility for what they’ve built
“This is what you’ve asked for, so this is what we’ve implemented”. Not only once have I come across this line.
I was writing and documenting the user stories by myself, down to the last word. Not only that, but also splitting and organizing user stories didn’t have too much input from the team.
In short, I rarely allowed them to take part in identifying the user stories they will work on later on.
So why would they then feel responsible for anything that I’ve written without considering their input?
This approach can easily disrupt the relationship between Product Owners and Developers.
First, because they don’t feel valued and they don’t feel they have a contribution other than doing what you require of them.
Second, when you see their behavior, without truly understanding what is going on, you will lose your trust in what your team can achieve.
2. Product Owners don’t consider refactoring when writing user stories
Many Product Owners don’t have a technical background but are experts in aspects of the business and users. So the outcome of their work will be user-facing work items, less focused on system improvement.
Why do you need refactoring? Simply to make your code more efficient, readable, and clean. And it also helps developers identify hidden bugs in the system.
Why should you consider refactoring when writing user stories? Depending on the area where your team will develop the code, to build new functionality, they will have to alter the current internal structure.
Over time, technical debt can increase, especially when it’s not taken care of immediately. Refactoring allows you to build new functionality without it having to depend on some code that was written in a hurry to meet a deadline.
When you keep adding new code over badly written code, the chances of poor product performance appearing are very high.
And who else would know that, better than the developers who have seen and worked with the code for so long.
That’s one reason Scrum teams are composed out of people with expertise in various domains. With everyone’s contribution and collaboration, you will build thorough products.
3. Splitting user stories too much or too little
The smaller the user stories, the easier is to take them through the implementation and testing cycle.
But how much should we split them?
It’s often said that a user story should be small enough but also bring value to the user at the end of an iteration. But many Product Owners are misinterpreting this.
A user story can bring value without having to be released by itself. The smaller the user stories, the more they have to be grouped before you can deliver them. But that is fine.
There is, however, a point where we should stop. Breaking them down too much can lead to two different things from a testing point of view:
- Testers will test in the same area of the functionality the same thing multiple times
- But also developers might not deliver enough functionality, so they have nothing to test
When should you not split anymore, from a development perspective? When developers have to change the same area of the code several times to get to the final shape if they can do this right from the start.
There is one more aspect to consider. When you spend too much time breaking down the stories instead of doing the work, then it’s time for you to stop and work with what you have at that point.
4. Too many questions arise during the sprint
Developers have to understand the business needs to know what they are building and why they build that piece of functionality.
With this in mind, it’s easier for them to make some tough decisions when the time comes and know what to negotiate with the PO.
As a Product Owner, you often need time to find out answers from stakeholders or from the client before your team can estimate a user story and plan it for the following sprints.
If you don’t clarify things enough with your team prior to the sprint, many delays can appear when you start the work on these items. You can end up with blocked user stories on your sprint backlog, the team cannot progress on.
But when most of these questions are addressed during the writing story workshop, you will have enough time to discuss these points with the stakeholders, by the time your next Refinement session begins.
You can easily replace one of your Refinement sessions with a workshop to write user stories whenever you start to work on a new feature.
Now you know why is beneficial to work with your team on building a backlog of work items. But what do you need to organize an efficient user story-writing workshop?
Tip 1. Identify and prioritize smaller objectives of your end goal
Think of your goal as long-term achievable outcome. It can be something like sending weekly newsletters to your subscribers.
Your objectives, in this case, will be the smaller steps you take to reach that goal. Such as finding an email newsletter tool, choosing a template, choosing your subject line and sender name
Depending on your authority as a PO within the organization, you can identify the goals and objectives by yourself or together with the client and other stakeholders.
Tip 2. Gather the team and spend the right amount of time in the workshop
As you identify the objectives, take them separately and create the user stories that fit under it, together with your team. Depending on the goal, the objectives can be more, or less complex.
Make an assessment and bring the right amount of goals into the workshop. Ideally, your outcome should be enough user stories to cover a couple of iterations. You don’t have to do this before each sprint.
But also, don’t spend time going through all objectives before you start the work. You might identify stories that won’t need anymore at a later time. The market changes so gather feedback from early delivered work.
But how should writing stories together look like? It doesn’t mean you have to write the entire description at this point. Identify what the user stories will be.
You will add the description after that and in Refinement, you can discuss the details and write together the acceptance criteria.
Tip 3. Group the user stories you identify (story mapping)
Start by building the flow users will have to go through to reach the final step.
From there, take each step and decompose it to see what subsets of actions you can identify. You’ll end up with something like the image below.
Miro has many other templates that you may find very helpful for your work.
Tip 4. Last, allow your team to add work items to the backlog
The team should feel comfortable adding technical tasks to the backlog.
These can refactor items, new systems that will make future implementation easier, and anything that refers to the technical side of an item.
Of course, they should discuss anything they add with you, before planning it for a sprint.
Consider that Sprints are not only for user stories, there are other things needed to offer the best experience to your users.
How does your team collaborate when it comes to writing user stories? You can leave a comment below.