5

Here is a scenario:

  1. User submits a story. As as a user I want X so that Y and Z.
  2. Story does not make in the sprint, and then the next sprint, and then the next, etc.

I am noticing stories lingering on the backlog for months while others are submitted and added to a sprint in short order. I see a risk that users watch their stories continuously pushed aside and disengage in the backlog/sprint process.

Is there a good rule of thumb indicating a story could or should be dropped from the backlog?

  • 3
    It would probably help us focus if you told us what your role is. Are you the product owner or a developer? – candied_orange Feb 17 '17 at 3:15
  • I am a developer. – Mike Henderson Feb 17 '17 at 9:06
6

Unless everyone agrees that the story is unnecessary or undesirable, there is usually no need or reason to remove it from the backlog. For the specific concern you raise, I don't see how outright removing a user's story is going to make the user feel more listened to. That said, if it has been decided (ultimately by the Product Owner) that the story will not be worked on (or is deferred to a later "version") the story should be marked as appropriate rather than constantly reevaluated. In my experience, you never reach the bottom of the backlog. It's completely normal that a story gets repeatedly deprioritized. This is part of the process of the "team" (in the broad sense) figuring out what is actually important. Most of the rest of this answer is really about how to deal the "risk" of a user "disengaging".

If a user is in a position to "track" their story, they are probably (or at least should probably) be able to be involved (at least as a spectator) in the prioritization process. When the story was added they should already have known its rough priority. If the user is actively involved, they presumably have other stories that are getting completed and should have little reason to "disengage". If the user is actively involved and all the user's stories are being deprioritized then either 1) this is a problem where features critical for a particular user are being deprioritized because it's unimportant to other users (or worse variants of this), or 2) the project isn't really aimed at that user's concerns and disengaging is probably an appropriate response.

In the (1) case, if the user isn't around to argue the case for why a story should be higher priority, get them involved. As a prelude to this or more generally, most probably in a sprint retrospective meeting but whenever, you should bring up to the team that you feel certain use-cases are being ignored which may potentially produce a system that is unusable for some users. If the user isn't very assertive, you or other team members may need to lend your voices to arguing for prioritization (of course, assuming you agree with the user). Some mild peer-to-peer "coaching" may also be useful if you feel equipped to do such a thing, or you can suggest it to a more appropriate person. For example, you may say something along the lines of "we want to build a system that works for everybody but we're constrained by the stack rank, so you should speak up and help people understand the importance of user story X". The important points to hit here would be a) explaining the process so the user understands how to work within it, and b) encouraging the user to advocate for stories that they think are important.

Things get more complicated (which is to say more political) if the user is needed for explicit (and to a much lesser but non-trivial extent implicit) buy-in. In this kind of scenario some "horse-trading" may be appropriate, though this is usually a bad sign. Ultimately, such a decision would come down to the Product Owner as they are the ultimate arbiter on prioritization. Since the value of software that is scrapped or just not used is quite negative, it can very much make sense to do some "unimportant" stories to gain buy-in. This kind of politicking usually happens at organizational levels higher than a developer, but you can definitely bring up concerns that the team may be failing to get buy-in from the users. This goes beyond Agile/Scrum. Agile methodologies try to use transparency and involvement to avoid these problems. In my experience as a developer, within larger organizations I've had to continuously and actively advocate for more involvement by end-users.

  • I'd feel more listened to if everyone is upfront about my request never getting into the project than stringing me along. If it is not going to happen, I can move look for another solution or just forget about it entirely. – JeffO Feb 17 '17 at 20:55
  • @JeffO I agree, hence my comments about marking the story appropriately if it is decided that it is not going to happen, but in my experience there are plenty of completely legitimate stories that just never "make the cut" at the end of a major round of work. Prioritizing more than a sprint's worth of work and, optionally, performing some coarse-grained prioritization of the whole backlog can help people understand the true priority of the stories. Nevertheless, you usually don't know which stories are going to "make it" until near the end of a round of work. – Derek Elkins Feb 17 '17 at 22:58
8

As a member of the IT team it is your concern but not your responsibility to try to ensure engagement by the various business stakeholders. I'd say that only the product owner can remove a story from the backlog and they have to talk to the person who submitted the story, explain why it was rejected and smooth things over. Nothing would look worse that the perception that IT was deciding which features to implement.

It has to be a business decision, based on an assessment of how much effort (cost) the story takes compared to how much value the story provides. In any well run agile project in a commercially driven organisation, there will come a point where the cost of the next release is going to be higher than the business value provided. At that point you can choose to do the next release or start to transition the project to business as usual support and move any incomplete stories to production support issues for consideration there. Maybe, after a few months of BAU, the user story will bubble up and become worthwhile - on that basis I'd advocate not removing any story unless it really is hopeless.

  • I like your "concern vs responsibility" wording. As a developer, it is "not your job" to deal with this, but it's definitely not something you should ignore. I also like that you talk about cost which I omitted explicitly talking about. It is not uncommon that users don't have any idea what it will cost to implement a feature. Being more transparent about costs can sometimes resolve these issues when a feature just isn't worth the cost of implementing it. (Ideally, you can quantify this). It often worthwhile to still keep these stories in the backlog though with very low priority. – Derek Elkins Feb 17 '17 at 3:28
3

Mcottle has already covered the case for bona fide stories never making a sprint very well. However there are genuine cases where a user story could be removed from the backlog altogether.

Not needed

These are stories that it was originally believed were needed but which aren't any more.

Superseded

These are stories which covered a small functional area but the work has been subsumed by another larger user story.

De-scoped

This is a valid requirement but one which is no longer satisfied by your team. For example, you may at one time have ensivaged having to design and write some software but on further analysis, you have decided to buy something in or there is existing software that can be re-used.


How you deal with these depends on your project management tool. Where I work, we have a junk iteration for stuff we definitely won't do which is kept separate from the main backlog.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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