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
Author
Messages
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?