Skip to main content

How would you encorporate non-trivial technical preceeding work into multiple user stories?

Last post 05:18 pm July 10, 2019 by Ian Mitchell
3 replies
04:17 pm July 10, 2019

A while ago we made a new feature. This new feature only works for situation a. We need to develop this feature to allow it to work for situations b and c aswell as a. I have made user stories to make the feature work in situations b and c (independently) however before both of these situations we must change how it works with situation a to make it more generic (it is very highly coupled to the inner workings/database tables of situation a at the moment). This decoupling will be a significant task within itself. My question is, how would you structure the user stories around this. My initial thinking is to have an 3rd user story which covers making the feature more generic. I don't love this for a few reasons: 1. this change won't add value to an end user. 2. this gives the 2 b and c user stories a dependency on this 3rd user story.


04:43 pm July 10, 2019

AFAIK, the dependency is there, however you write this up...

It might not add value to the end user, but that is not the only type of value there is, right? Adding value to the team, the organization, or adding value by making code more future proof, remove technical debt, etc, its all value.

I would make a third story to make it more generic first, and put it above B and C on the backlog


04:58 pm July 10, 2019

+1 for @Xander's response.

I have stated many times that I interpret all items in the Product Backlog as having 2 values..negative until addressed and positive after it is addressed.  In the case of refactoring the back end you are providing value to the organization because that work will make it possible to add even more functionality on top of the existing. It also adds value to the end user for the same reason. Isn't the possibility of getting more and more functionality in shorter duration considered value, unrealized but still value. 


05:18 pm July 10, 2019

My initial thinking is to have an 3rd user story which covers making the feature more generic. I don't love this for a few reasons: 1. this change won't add value to an end user. 2. this gives the 2 b and c user stories a dependency on this 3rd user story.

Regardless of dependencies and perceptions of value, would this make the technical debt you seem to have incurred more transparent?


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

Please note that the first and last name from your Scrum.org 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.