Your next Sprint is getting close, and you’ve run out of user stories. What now? What will your team work on, considering the empty Product Backlog coming ahead?
If you blame yourself for letting this happen, know that no matter how experienced, many Product Owners encountered this situation at least once.
When it happened to me, I was worried because I knew everyone will blame me for it. So I had to get some work done to hand it over to the development team.
And it wasn’t a onetime situation. But the good part is that this gave me the chance to know what signs to look out for before it happens.
Signs that your Product Backlog is running out of working items
- There’s not enough work on the Backlog for the next one, two sprints
Ideally, the Product Backlog should contain working items as follows:
- User stories that are well detailed for the upcoming sprint, or even better for the next two sprints
- User stories that have enough information for a good understanding, but might miss a couple of details to start the development
- Epics with high-level details you can break down together with the development team
When you notice that the only working items that you have prepared do not add up to the speed of the team in a sprint, then you know the Backlog is running out of working items.
- You cannot work on your user stories because something else is blocking them
Examples of such blockers:
- You need to wait for other teams to release a piece of functionality
- You created dependencies between the user stories on the Product Backlog
I used to work in a company where several teams handled different components of the same product. And each team was developing their own features for their component.
Sometimes, one team had to wait for another one to finish with their feature so that they can start working on their own.
Another blocker can come from the Product Owner. It happens when the Product Owners don’t collaborate with the rest of the team on documenting user stories.
The development team has a very important role in breaking down user stories. They can identify technical dependencies between items.
This helps the Product Owner take a decision that is based on their insights as well.
- The company changes its vision too often
You have everything prepared to work on the next feature, but suddenly all priorities change.
This could show you two things:
- The company keeps up with the market and competition
- The company has no long-term vision
The first option is a good thing. The second one, though, is harming your work as a Product Owner and the work of your entire team.
In either case, talk with your company leaders to ensure that communication towards the product department is transparent.
Practical solutions to getting your Backlog ready before every sprint
- Prepare enough user stories for the first few days of your sprint
Before adding them to a sprint, you’ll have to refine and estimate the user stories with the team.
When there isn’t enough time for the Product Owner to create enough items for an entire sprint, having just a couple of user stories for the first few days can get you out of the trouble.
Then, during the sprint, build up a more solid backlog. Schedule a couple of short refinement sessions throughout the sprint and clarify some working items with the developers.
They will help you with new working items or maybe unblock some that are already created.
- Small projects and improvements
Another thing that you will find beneficial is having one or two small projects on your backlog. These are projects you’ve always wanted to work on, but never got time because of other urgent projects.
However, do not crowd the Backlog with too many such projects, otherwise, you’ll create an oversized backlog that will be very difficult to organize and manage.
- Validate a system with a proof of concept
We use proof of concepts to ensure any further investments in the product and to prove that a solution will work. When your Backlog is low on working items, you can try to validate some ideas you never had time to look into.
Because it’s a small piece of work, you can quickly work with the team to create some user stories.
First, you need to have a set of requirements:
- Identify and prioritize high-level business requirements
- Identify high-level technical needs
Then, work with the developers to add some items on your Backlog:
- Create a couple of user stories that will support your idea
- Test and implement the solution
- Measure the PoC’s outcome
Lastly, review the work done, to accept or reject moving to the next phase.
- Work with other product people and department leads
When you’re not exactly overflowing with ideas, it is worth to ask for help from other people that are close to clients.
- Have bi-weekly discussions with other Product Owners within the company
- Have frequent talks with the support department or with their lead
You should get used to having regular discussions with other Product Owners within the company.
This can help you identify places you can offer your support by bringing in your team and land a hand to other teams that might struggle with deadlines. This is a good place to invest their spare time if the company structure allows it.
But you can also ask for help with your Product Backlog. If you have no clue about what you can do next, talk with a fellow Product Owner to help you out with some insights and ideas.
In the support department, you’ll find the people who work the closest with your customers. Many ideas can emerge from a conversation with them. Ask them about any requests they may have received.
It can be an improvement, or it can be some new functionality that a customer may need.
Analyze these requests to see if any of them fit into your Product Backlog. And this is how you gain some more time to create items for that next major feature.
- Talk with your tech leads
Many Product Owners do not trust their development team being creative. But you will be surprised how much they can help you with ideas for new working items.
Have a brainstorming session with the tech leads about:
- Generating items to fix some old bugs
- Looking into the technical debt
What is important to consider when working with your tech leads, is making sure they understand the upcoming work.
You should create the new items as support for what’s coming next on your roadmap. Identify those stories that will make things easier for your future project.
Be careful not to crowd your Backlog too much. Create just enough work until you shape the Product Backlog with the stories that bring business value.
- Improve your communication with the company’s leaders
When priorities change from one month to the other, it’s very difficult for the Product Owner to come up that fast with an ordered and solid Backlog.
You need time for multiple activities:
- Talk with stakeholders to understand the business need
- Make research to see how that need fits into your product
- Have a session with the developers to describe the requirements
- Work with the developers to refine the requirements and estimate the stories
So talk with your leaders to let them know why need to know when changes occur before they do. You need time so that you can prepare in advance. Better communication with the product team and transparency is going to simplify the work for the entire team.
And that’s how the next sprint won’t catch you without having at least a couple of work items for the team.
