As Product Owner you are in charge of the backlog. There are two wrong situations that Product Owners have to be aware:
- Empty Backlog: if team members have no user story in the backlog they will be blocked until the Product Owner writes (and discuss user stories with team members) and add user stories in the backlog. Speaking in Lean principles: the Product Owner is wasting the time of development because his fault.
- Fat (or overloaded) Backlog: this situations happens when team members have to deal with a lot of user stories in the backlog that is useless. Why? Because all the Scrum team (including the Product Owner) will get knowledge Sprint over Sprint so it is unnecessary to put so many details in future user stories that should be refined (or removed from the backlog).
Getting your Backlog ready!!
I am using a phrase that liked me “Getting your Backlog ready” from Jeff Sutherland who uses that in a webinar about “Slicing User Stories” (www.scruminc.com). Indeed, this webinar was conducted with Jeff Sutherland, and the industry’s leading expert on story-slicing, Ellen Gottesdiene.
The idea is to have small and good user stories to work for the next two Sprints. Many times there are any user stories that could not be developed by any dependency so it has to be removed from the Sprint Backlog (and return to the Product Backlog until the dependency will be removed) because of that you need extra user stories (user stories for the next Sprint).
In one of my last clients I run into with a backlog plenty of user stories that I have ever imagined in my life. That backlog had more than two hundreds user stories. What was the reason of this “Fat” backlog? Well, the client was using Design Thinking and from there they were feeding the backlog. The problem was that the Product Owner was forcing team members to read all the user stories that obviously created several conflicts between him and team members that considered a waste of time to review a lot of user stories.
To conclude, Product Owner has to include only enough user stories to cover just two Sprints and if he needs he can include in the Product Backlog user stories at big level but not forcing to team members to take them into account.