Who should be allowed to add stories to the product backlog?

Question

What is the best practice for that prevents the backlog from becoming a mess, but also maintaining developer productivity

Who should we allow to add stories to the product backlog? And how do you make sure these stories meet certain requirements?

For example I find a few small css bugs during the development of Feature X. Should I then as a developer be allowed to add a story describing the bugs to the bottom of the backlog? Or should I discuss it with the product owner?

Having all ideas/bugs go through the product owner sounds like possible bottleneck.

Answer 1

The usual approach is that anyone can add stories to the backlog. The product owner prioritizes them and the team estimates them. Story quality issues generally get taken care of one way or another in planning meetings or retrospectives.

That means the product owner isn't a bottleneck as long as you're satisfied with the priorities he's assigning. Otherwise, make your case.

Answer 2

Whereever I have worked in software development, there was always an equivalent of a backlog, always a list of bug reports, and always someone responsible for the priorities (an equivalent of a PO), so your question, though it uses Scrum terms, is IMHO far from beeing restricted to Scrum.

A quick google search for "scrum backlog bugs" revealed that some teams separate bugs / issues from "new feature" stories, other's don't. Sometimes issue trackers are used, sometimes a Wiki, sometimes everything goes directly into the backlog, etc., and there is no consensus "which is better". So the first thing you should clarify in your team how you want to handle this, what does your team want to see in the backlog and what not, and what does your team think will work best for your case.

If you made the experience that if everyone is allowed to add anything to the backlog messes its up, it will probably better to separate user stories from bugs. The requirements how a good bug report should look like are probably different from the requirements how a good user story for a new feature should look like, which might be another reason, too. Nevertheless both will end up in tasks for the developers, which might be a reason to keep them in one place.

However, for most products it makes sense when bug reports can be given by anyone (users, testers, developers, marketing people, whoever notices a potential problem). "New features" should probably be discussed with the PO as part of the process when adding them to the backlog. Your PO should decide if he wants to put the stories into there by himself to do some editorial work beforehand, or if anyone can put the stories to the backlog and he does the editorial work afterwards. But for bugs, especially the ones which look severe to the reporter, there should be no discussion needed to add them to the issue tracker, or backlog or buglist document, or whereever you keep them. "No discussion" does not mean to put the bug report anywhere silently, quite the opposite. When a bug report is added, and the reporter thinks it is probably not a minor one, the PO (or whoever is responsible) must get informed.

As a final note: to make the right decision for your team how to manage this, it makes quite a difference what size your product has, how many people are going to report bugs and new stories, and if you get one but report per week, a dozen or several hundred.

Answer 3

We allow posting bugs to bottom of product backlog for everyone in the team. The item should correspond to certain rules (e.g. conditions for reproducing, what's the correct behaviour, etc) New features, however, are added to separate list 'Ideas', from which the PO pulls them into Backlog (and obviously turns them into a PBI with more information if needed)

Answer 4

We usually do it like this: Product manager adds stories with descriptions to the product backlog. Our scrum master (who is also team lead) reviews those stories and requests additional feedback for stories that are not defined clearly enough. During the planning week, the team breaks down each of the stories to tasks. If bugs are raised, our team lead places them on backlog, with priority assigned too each of them.