Should we limit who can submit stories in Scrum?

Question

A few of the managers at my company have decided that the stack of stories is too high, so they're going to truncate the backlog and the number of people who can write stories.

The goal being, only approved story submitters can create feature requests. Is this antithetical to Scrum? Doesn't it just mean the Product Owners are being too lazy to vet cruddy stories? Our backlog is at about 1400, I recently went through the backlog and figured, on my own as a scrummaster/developer that I could shrink it to about 600.

What advice should I give the Product Owners around this idea? Should I vehemently oppose this idea as a Scrum Master?

---

What is the long term plan for this project?

• these are multiple projects that usually have a 6-12 month of development work until they're done and then continuously improved until they're retired.

Will there be some release point after which development will pretty much stop, or will it have continuous development for an indeterminate time with many releases?

• Development probably will only stop when feature requests stop being submitted by customers and other stakeholders

You said you found a large number of stories that you could remove--are these duplicate stories, useful but poorly written stories, or stories that could be useful but you don't see the development team ever getting around to them?

• a few duplicates, many potentially contradictory stories. Lots are ones that none of us see the dev team getting to as written, but they may be the seeds for things that need to be done.

And who exactly has been entering the stories you think could be chopped (developers, product owner, other customers)?

• Developers and users of the platform (our guys, not paying customers) maybe 3% are customer requests. Most come from end users, we mainly develop in-house utilities that are used to support many customers - some of the tools produce reports and things that customers see, but those customers don't enter stories. Product Owners, for the most part, don't write the stories, although they may rewrite 'em.

Answer 1

Should we limit who can submit stories in Scrum?

No, but you should ensure that individuals are educated enough to know when is a good idea to add stories as well as having solid processes to do it.

Great ideas can come from everyone and it's well known that giving freedom to people to work on what they have passion for makes them do a better job.

Elaborating on the two points what I'm suggesting (based also in the fact that I think you need to investigate why you can shrink that much the backlog):

• Focus on educating individuals to understand when is advisable to add stories. This will include sessions to make sure that everyone understand what are the goals of the project, what are the priorities, what are the problems, etc.

• Create a structured and organised process to add items to the backlog. Perhaps you can have sessions organised by department every X weeks. Everyone should be able to provide ideas, discuss them, and decide which ones actually go into the backlog. Creating an "etiquette" or "template" for when/how stories should be added, might also be useful.

Finally, if there's no turning back, I want to mention that "completely" removing their privilege seems like a very strong decision. Incremental steps work much better in this cases, as you can have a very negative effect on some people and in turn reduction of productivity, creativity, enthusiasm, etc.

Answer 2

From the Scrum Guide:

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes: [...] The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

Meaning... it's the Product Owner (PO)'s call. As you ask:

Should I vehemently oppose this idea as a Scrum Master?

Again, from the Guide:

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide.

So, going strictly by the Guide, your job as Scrum Master is to make sure the Team is following the Guide. And the Guide says it's the PO's call.

That being said, you can certainly give advice, if you wish. I recommend that this would be a good topic to bring up at the next Retrospective. Discuss with the whole Team, but first make it clear that the ultimate decision lies with the PO.

---

Also of concern:

The Product Owner is one person, not a committee.

This responsibility needs to be given to one person, whom is the PO. There should never be multiple POs for one project. While the PO may delegate to other, pseudo-POs, there must be only one actual PO who remains accountable for the Product Backlog.

---

Finally, my advice: Start a Sprintly Backlog Refinement meeting where either you or the whole Development Team meet with the PO and refine the backlog. As you mentioned:

Our backlog is at about 1400, I recently went through the backlog and figured, on my own as a scrummaster/developer that I could shrink it to about 600.

You should be doing this alongside the PO (assuming the PO is unwilling/unable to do it by him/herself). Again, the PO remains responsible for the Product Backlog - don't go overhauling it on your own.

Answer 3

Excellent answers already, but I will add a bit.

Should we limit who can submit stories in Scrum?

Anyone can propose a story is added to the backlog, but the process is typically as follows:

• The person who is suggesting the story explains it to the Product Owner
• If the Product Owner agrees it is a valid story and makes sense for the product they tell them to proceed in adding it to the backlog

Our backlog is at about 1400

It is worth remembering that the aim of Scrum is to respond quickly to change. An overly long product backlog can:

• Create resistance to change: "We don't want to accept feedback on the product as the backlog is already very full"
• Disappoint stakeholders: "My story has been on the backlog for a year and it is still nowhere near the top!"
• Create clutter: It is difficult to read/review a very long backlog

A good approach I have seen teams take is to put a time limit on the backlog. For example, some teams say that the backlog should not have more stories than they can complete in the next 3 months.

Answer 4

I don't think it will be a good idea to limit adding the user stories to specific individuals.

From your explanation, I get that the intention is to reduce the count from 1400 to some number.

Considering Product Owner is accountable to keep Product Backlog in check, this decision might look like no-brainer. As a ScrumMaster, you may want to understand Product Owner's point of view in the matter.

There can be a group of product managers, but in the end, voice should be one.

You can talk on the lines of creating some kind of delegation to vet user stories and Product Owner will be responsible to come up with a consensus and order the product backlog properly.

Answer 5

I'm going to answer with questions!

First question: what's the problem? A long product backlog, in and of itself, isn't necessarily a problem. It's really over to the PO to manage the product backlog as they see fit (and to decide if an issue will or won't get done).

This becomes a bigger problem if the long backlog makes it hard to generate the sprint backlog. If happens then, as a scrum master, you're quite right to hold the PO to account. But this doesn't amount to limiting the backlog, but you might help understand what a 'good' story looks like (I tend to push back on acceptance criteria; if these aren't defined, then the story is probably in bad shape).

From your more detailed answers, it sounds like there's a process that's conflated user suggestions with user stories. You don't want to discard/prevent suggestions being captured - but there is a question as to whether the product backlog is the right place to do this. That decision is on the PO - but subject to producing a sprint backlog. As a scrum master, you can offer to help (the techniques here are more around value mapping - I've used impact mapping recently, which is very helpful).

Answer 6

I have sympathy for the POs approach because it sounds like the PO is trying to get at the root of the problem.

The root of the problem being that a backlog of 1400 issues is not manageable. I'm guessing that the PO is concerned that some people are adding poorly thought through issues that are never going to be looked at & so are just adding to the bloat.

So to the SMs point if he can identify 800 duplicate/rubbish issues then that suggests that poor quality issues are being pumped into the backlog.

Solution

• Create a new project to dump the entire backlog into

• Limit the access to the original project to the PO/SM

• Leave the access to this new project open

• Have the PO/SM selectively move issues from this new project backlog back in to the original project backlog to feed the upcoming sprints

• The PO/SM can then ruthlessly prune the issues in this new project

If there remains concerns about people adding stories run a query & identify who are the main culprits adding issues that are subsequently flagged as duplicate or rubbish.