Skip to main content

Obsolete user story

Last post 02:56 pm May 17, 2023 by Daniel Wilhite
6 replies
09:35 pm May 9, 2023

What would you do as SM when the Delivery team identifies an obsolete user story in the middle of a 2-week Sprint. 
Team had committed to a story in Sprint Backlog and they are mostly innovating, rather than 'Run' work. As they learned more about the new product that they are working on, the user story became invalid/obsolete.

Should the user story be removed? Or should a 'never worked upon' user story moves to DONE?

06:10 pm May 10, 2023

Scrum is mechanism of discovering and minimizing risks and removing easte, not the tool to push production.

In this case Scrum already successfully achieving the task of  identifying the problem in the operations, which is a success, not a failure.

The task which is obsolete is obsolete. Is gone for good. 

07:41 pm May 10, 2023

The team does not commit to work in the Sprint Backlog. The team commits to the Sprint Goal.

When you're dealing with the unknowns and uncertainties of complexity, you are likely to find that some work you thought you needed to do is unnecessary, just as you are likely to find that you need to do something you didn't plan on doing. This should not be considered unusual or unexpected. How you indicate this depends on your context, though, and what kind of information you need. Some teams want to keep track of this work and learn from it, since time and effort was invested to get it ready for a Sprint and select it at Sprint Planning, but other teams can simply discard the work and move on. It's up to the information needs of the stakeholders and, perhaps, the tools that you are using to manage the work.

09:27 pm May 10, 2023

What would you do as SM when the Delivery team identifies an obsolete user story in the middle of a 2-week Sprint. 
Team had committed to a story in Sprint Backlog and they are mostly innovating

I don't think they are. If they were innovating, they would not have committed to such a thing. They'd have recognized that a user story is a placeholder for a conversation about a potential requirement. When brought together in a Sprint Backlog, with a Sprint Goal commitment worth aiming for, these conversations are a coherent forecast of the discussions then needed to innovate.

08:03 pm May 11, 2023

As a Scrum Master, I wouldn't do anything with the item specifically.  The Sprint Backlog is made and owned by the Developers.  They should decide what to do with that item just as they do with any item that they feel is still viable. I would suggest that conversations occur with the Product Owner to help them understand how and why it is obsolete.  And I would also bring up the item in the Sprint Retrospective to see if there is anything the team can learn about the situation.  

The Scrum Guide states this in the section that describes the Sprint Backlog

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

It is expected that the Sprint Backlog will change during the Sprint to support the Sprint Goal as more information is discovered.  Items may be added, some removed, some modified.  That is normal in a situation where information is never fully known before the work begins. 

07:11 am May 17, 2023

A user story is only a requirement; what would be the value of the team spending time and money developing a requirement that does not offer value?  What can the team learn from both, not needing to develop the unnecessary requirement (perhaps product knowledge), and the process of how this story got into the Sprint (perhaps improved refinement).  The question, (1) If the item is removed from the Sprint, when would the team discuss and how would the team learn how the item got there in the first place? :)

02:56 pm May 17, 2023

At the time the decision is made to remove it from the Sprint.  Why postpone the learning?  At the very latest, it could be discussed at the Sprint Retrospective.  In my experience, the sooner you discuss the situation, the more that is known and the better the learning. 

Empiricism is embedded deep into Scrum.  It is not just something you do at the end of the Sprint.  It is something you do continuously.  You do something, as new information is uncovered, you inspect the previous decision and adapt if necessary. 

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.