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?

  • Can you expand? Adding 10 - 40 PBI's doesn't necessarily seem like a lot. In what ways is it making things harder for your PO to maintain?
    – Daniel
    Commented Dec 26, 2015 at 23:44
  • @Daniel: at peak it could make about 100 PBIs from users-feedback only. Above that there are PBIs related with long-term roadmap. It makes it hard for PO to keep backlog manageable even for himself. Commented Dec 27, 2015 at 9:10

2 Answers 2


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.

  • I agree that grouping is probably the best bet. I assume that many feedback items are related to the same area because they're coming out of stories for that one sprint. I'd also point out that, while I really prefer user stories when possible, not all PBI's are user stories. You shouldn't kill yourself trying to turn something into a user story that's just a group of tasks.
    – Daniel
    Commented Dec 27, 2015 at 15:52
  • @Daniel you're right and I rephrased my answer a bit.
    – Tob
    Commented Dec 27, 2015 at 15:59
  • Grouping makes sense here. I realized that my original intent for this question was bit different. Nevertheless I hope it brought insights to some people. Commented Dec 29, 2015 at 16:21

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.