Forums

By posting to our forums you are agreeing to the Forum terms of use.
Should this be a story?
Last Post 15 Mar 2013 05:31 PM by Charles Bradley. 10 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
randyh
New Member
New Member
Posts:35
randyh

--
11 Mar 2013 06:15 PM
    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.
    Ravi Vajaria
    New Member
    New Member
    Posts:12
    Ravi Vajaria

    --
    11 Mar 2013 07:15 PM
    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.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    11 Mar 2013 11:36 PM
    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.
    Susanta
    New Member
    New Member
    Posts:20
    Susanta

    --
    11 Mar 2013 11:52 PM
    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.
    Susanta
    New Member
    New Member
    Posts:20
    Susanta

    --
    11 Mar 2013 11:53 PM

    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.

    Ryan Cromwell
    New Member
    New Member
    Posts:89
    Ryan Cromwell

    --
    12 Mar 2013 12:09 AM
    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.
    Sanjay Saini
    New Member
    New Member
    Posts:81
    Sanjay Saini

    --
    12 Mar 2013 01:45 AM
    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.
    Ryan Cromwell
    New Member
    New Member
    Posts:89
    Ryan Cromwell

    --
    12 Mar 2013 08:43 AM
    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.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    12 Mar 2013 09:08 AM
    > This aligns with Ian's and Sanjay's responses I believe.

    Yes, that aligns with my perspective.
    randyh
    New Member
    New Member
    Posts:35
    randyh

    --
    12 Mar 2013 11:54 AM
    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.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    15 Mar 2013 05:31 PM
    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+Str...nt+Backlog

    I also agree that this technical thing should not go on the PB.
    You are not authorized to post a reply.


    Feedback