What is the best way to handle small items in a backlog?

Question

Background. There is a web platform as a product. There are few teams contributing to it. Usually a team works on a feature, delivers the feature and maintains it. There are millions of end users and the adoption of features takes weeks. During this period new users share their feedback. Let’s say there are about 3 features on average being actively supported. This setup generates dozens of tiny improvements gathered throughout the time. Very often, when team is already focused on a new feature, end-users feedback is still being provided. DT (Development Team) works in Scrum. Jira Agile is used as a PjM tool.

The issue. Product Owner selects most valuable pieces of feedback and turns it into the PBIs. As a result, there are lots of small PBIs (between 10 to 40). That in turn makes the Backlog hard to maintain.

Problem statement. What’s the good way to keep the backlog maintainable for PO and useful for the DT?

Answer 1

The backlog consists of PBIs like Epics and User Stories. I really like using User Stories. That's why I'll stick on the term in the following. But be aware that other representations might be more useable sometimes (as @Daniel pointed out in his comment).

A few User Stories can be finished in a sprint. User Stories are broke up in tasks during sprint planning to be traced during a sprint. A task should be moved each day on the task board.

The feedbacks seems not to fit into this rough definition of User Story. They seem to be closer to a task.

I would recommend to collect several of the feedbacks in one story or epic. Best would be to expand an existing story - which is not part of the current sprint.

Nevertheless, this assignment is a job to be done and if this is too much work for the PO, the PO needs assistance to get it done.

Answer 2

Two main options here:

• Give the PO help
• Give the PO better tooling

The Product Backlog is:

an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.

For a product of significant complexity, the backlog will grow to be non-trivially large. The Scrum Guide puts it this way:

As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list.

As @Tob mentioned, this might be a good time for your Product Owner to enlist some help. This help can be creating Product Backlog items (user stories, bugs, features, etc), refining PBI's, talking to stakeholders, etc.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

It is best for these helpers to be on the Dev team to reduce the communication overhead of workers outsidethe Dev team doing the work. Business analysts for example could work as Developers on the Dev team; they would occasionally help refine the backlog, design UI, write/execute tests, and occasionally code if need be. Alternatively, you might have stakeholders help the PO by adding to and refining the backlog.

Also, look into other tools to help manage your backlog. I've had good experience with Pivotal tracker and the new Visual Studio Team Services is quite good.

With improved tools however, be cautious not to sacrifice agility. Remember the agile manifesto encourages us to value individuals and interactions over processes and tools. Always seek to solve problems with highly motivated people if at all possible.