olly - Fotolia
I often hear teams complaining that their product owner doesn't have time for them. They do not get their user stories in time, planning meetings are cancelled or held without the product owner. These problems can seriously hamper Agile teams.
The official Scrum Guide states that "the Product Owner is responsible for the Product Backlog, including its content, availability, and ordering." It doesn't prescribe who should produce backlog items.
Product owners who are new to Agile may insufficiently understand how Agile can work. They are used to projects where all requirements are defined up front and where there is no interaction with teams during development. Because teams may have a better understanding of Agile, they can consider coaching product owners. Work with them to show how to build a backlog, write Agile user stories, and manage requirements with Agile.
Alternatively, teams can (preferably, together with the product owner) raise the problem to senior management, who can ensure product owners have sufficient time to work with the teams.
If the issue isn't resolved, teams will have to find other ways to build up understanding of customer needs. One approach would be for team members to work directly with customers or customer representatives who can tell them what the customer needs.
At a minimum, you want a product owner to review the Agile user stories, give feedback on the descriptions and acceptance criteria, and approve user stories. If that isn't possible, it is questionable if there is a need for the product. My suggestion is to stop the work and ask for another product owner who has time to work with the team, otherwise the risk of developing functionality that customers don't need is too high.
If the product owner doesn't have time to write Agile user stories, team members can write the user stories themselves, and have them checked and approved by the product owner. Meanwhile, they can coach product owners and influence managers in the organization to improve collaboration.
Improving Agile security
Avoid too many user stories
Agile best practices