Should this be a story?
We have technical debt that we would like to track so that it can be worked on sometime in the future.
A component throws warnings when it is built. We would like for these warnings to be addressed so a new PBI has been added to the backlog:
PBI: Address warnings from X component that are outputted during the build
Is this where this should go? This warning existed before we started scrumming so there's no existing user story to link to.
I do not think this should be a story. It does not seem to add any business value. Should be addressed when making changes to X component as part of any future story that adds business value.
Technical debt is often best handled by raising it as tasks against user stories.
If there is no relevant story, consider estimating how much technical debt you intend to pay off in an upcoming sprint, writing a generic story for making a payment, and then raising tasks against it such as the one about dealing with warnings.
Incidentally, defects can be handled in a similar manner. So can waste, if you want to give it some transparency.
Technical Debt should be a user story; as "user" story literally says - any technical issue that does not have any association to user story should not be a part of such.
It should be handled thru task)you may keep track thru task list) along with relevant user story.
Posted By Susanta on 12 Mar 2013 12:52 AM
Technical Debt should NOT be a user story; as "user" story literally says - any technical issue that does not have any association to user story should not be a part of such.
It should be handled thru task)you may keep track thru task list) along with relevant user story.
Does your product owner or customer care about these warnings? If no, my vote as a team member would be not to include them in the Product Backlog. Your team - your choice.
This may be a user story for your build engineer and theme of it could be Quality. Generally technical debt don't add any direct business value to customer in short term but they may in long term. Also they may help team in delivering fast. I have seen team keeping 10% time for technical debt each sprint.
Does your product owner or customer care about these warnings? If no, my vote as a team member would be not to include them in the Product Backlog. Your team - your choice.
I'd like to expand on my preference as a team member.
What you're describing isn't necessarily what I would call debt, but instead undesirable technical behavior. It's a semantic difference, but somewhat important IMO. Technical debt is something that inhibits your ability to deliver new value to your PO.
You don't know what decisions you make today in good faith will slow you in the future. For that reason, technical debt is something you will always have and should be solving in the context of new value. This is why I would likely not put it on the backlog, but as new value PBIs came along I would solve my Technical Debt in the context of those PBIs. This aligns with Ian's and Sanjay's responses I believe.
Again, if your team were to choose to put them on the PB... I'm ok with that. But treat that choice as an experiment like any other retrospective outcome and inspect on it's impact to your PO, grooming, etc.
> This aligns with Ian's and Sanjay's responses I believe.
Yes, that aligns with my perspective.
Great replies so far guys. I'm going to summarize what I understand the suggestions to be:
Point 1: Not technical debt since it does not inhibit the team from delivering new value to the PO
Point 2: PO Probably doesnt care about this particular behavior (we checked - he doesnt)
Point 3: The team wants to work on this sometime in the future
Options for action:
A) Include in the product backlog as a PBI with the understanding that it is not a real PBI
B) Dont add it anywhere. It can be added as a task (or simply addressed without a task card) to support the teams commitment to a future story that involves the module
C) Add it as a task to a "technical wishlist" somewhere and have the team work through this list when they have time (perhaps when they undercomit to a sprint?)
D) Add it as a task to a "technical wishlist" and attempt to relate items on this list to stories when doing planning.
We're not quite sure what to do at this point. We have our options and have already added it as a PBI to the backlog but from the advice given in this thread so far, it seems like we should be exploring the other options instead.
One strategy I coach for handling this stuff is the "Dev Team Improvement Backlog". All the details and preconditions are here:
http://www.scrumcrazy.com/Scrum+Strategy+-+The+Dev+Team+Improvement+Bac…
I also agree that this technical thing should not go on the PB.