Loading ...
Sorry, an error occurred while loading the content.

Should issues and defects create user stories on the product backlog?

Expand Messages
  • Sten
    No, I am not talking about bugs we create from the user stories that are completed during sprints. The team is configuring an Off-The-Shelf (OTS) product and
    Message 1 of 5 , Dec 2, 2010
    • 0 Attachment
      No, I am not talking about bugs we create from the user stories that are completed during sprints. The team is configuring an Off-The-Shelf (OTS) product and in this way adjusting functionality that is already in the product, but also modifying and implementing new functionality by plug-in scripts and small chunks of code.
      When there are bugs detected in the product (that is also under development, but handled by the supplier) we find our selves spending a lot of time testing new releases of the product, logging issues and bugs. We do have dates on when to expect new releases containing new and updated functionality from the supplier, and may therefore plan the testing a little up front by defining user stories.
      How should we organize the work so that it is visible how much effort the bugs in the OTS product really demands?
      Fixing bugs introduced by the external manufacturer wouldn't be value for the business, would it?
    • Jussi Mononen
      ... Hi Sten, if you can t fix the bugs then they do not belong to your backlog. These issues sound more like impediments. -- Progress doesn t come from early
      Message 2 of 5 , Dec 2, 2010
      • 0 Attachment
        On 3 December 2010 08:43, Sten <steoj@...> wrote:
         

        No, I am not talking about bugs we create from the user stories that are completed during sprints. The team is configuring an Off-The-Shelf (OTS) product and in this way adjusting functionality that is already in the product, but also modifying and implementing new functionality by plug-in scripts and small chunks of code.
        When there are bugs detected in the product (that is also under development, but handled by the supplier) we find our selves spending a lot of time testing new releases of the product, logging issues and bugs. We do have dates on when to expect new releases containing new and updated functionality from the supplier, and may therefore plan the testing a little up front by defining user stories.
        How should we organize the work so that it is visible how much effort the bugs in the OTS product really demands?
        Fixing bugs introduced by the external manufacturer wouldn't be value for the business, would it?

        Hi Sten,

        if you can't fix the bugs then they do not belong to your backlog. These issues sound more like impediments.

        --
        "Progress doesn't come from early risers — progress is made by lazy men looking for easier ways to do things." - Robert. A. Heinlein

      • Sten
        You are probably right. Then how to go about solving that impediment? Would it not be constructive to contribute as mutch as possible towards a working end
        Message 3 of 5 , Dec 3, 2010
        • 0 Attachment
          You are probably right. Then how to go about solving that impediment? Would it not be constructive to contribute as mutch as possible towards a working end product?
          The fact that some of these issues also affects our own user stories and delays them causes even more problems for us.
          I understand we cannot organize our selves out of this, but it does not seem to be an option to ignore it either.
          Are you suggesting that this is best handled as reduced velocity by the team?

          /Sten

          --- In scrumdevelopment@yahoogroups.com, Jussi Mononen <agilepoodle@...> wrote:
          >
          > On 3 December 2010 08:43, Sten <steoj@...> wrote:
          >
          > >
          > >
          > > No, I am not talking about bugs we create from the user stories that are
          > > completed during sprints. The team is configuring an Off-The-Shelf (OTS)
          > > product and in this way adjusting functionality that is already in the
          > > product, but also modifying and implementing new functionality by plug-in
          > > scripts and small chunks of code.
          > > When there are bugs detected in the product (that is also under
          > > development, but handled by the supplier) we find our selves spending a lot
          > > of time testing new releases of the product, logging issues and bugs. We do
          > > have dates on when to expect new releases containing new and updated
          > > functionality from the supplier, and may therefore plan the testing a little
          > > up front by defining user stories.
          > > How should we organize the work so that it is visible how much effort the
          > > bugs in the OTS product really demands?
          > > Fixing bugs introduced by the external manufacturer wouldn't be value for
          > > the business, would it?
          > >
          > Hi Sten,
          >
          > if you can't fix the bugs then they do not belong to your backlog. These
          > issues sound more like impediments.
          >
          > --
          > "Progress doesn't come from early risers — progress is made by lazy men
          > looking for easier ways to do things." - Robert. A. Heinlein
          >
        • Jussi Mononen
          ... You could escalate the issues, re-prioritize your own stories so that you can proceed with something else. Of course you can and should assist the supplier
          Message 4 of 5 , Dec 3, 2010
          • 0 Attachment
            On 3 December 2010 10:55, Sten <steoj@...> wrote:
             

            You are probably right. Then how to go about solving that impediment? Would it not be constructive to contribute as much as possible towards a working end product?
            The fact that some of these issues also affects our own user stories and delays them causes even more problems for us.
            I understand we cannot organize our selves out of this, but it does not seem to be an option to ignore it either.
            Are you suggesting that this is best handled as reduced velocity by the team?

            You could escalate the issues, re-prioritize your own stories so that you can proceed with something else. Of course you can and should assist the supplier to track down and correct the bugs, for example, by providing reproduction instructions, test cases, volunteering to test release candidates for the fix etc.

            But you need to communicate that something gets delayed because of external dependencies to your own stakeholders. They should understand that :)

            --
            "Progress doesn't come from early risers — progress is made by lazy men looking for easier ways to do things." - Robert. A. Heinlein

          • JackM
            There are many opinions on this topic and i am not sure you could say one is better than the other. What i will say however is that for me i don t see them as
            Message 5 of 5 , Dec 6, 2010
            • 0 Attachment
              There are many opinions on this topic and i am not sure you could say one is better than the other. What i will say however is that for me i don't see them as stories but lumped in with other tasks for a story

              Here's what we do at the current company ....

              Story card goes up on the wall, together with all the tasks. If a bug is found once the story is release to QA the bug goes up on the task board the next day. We track this on the burndown i.e. hours are accounted for.

              It can get unwieldy if there are lots of bugs so be careful

              I have also worked in companies where we just kept the bugs in the bug tracker seperate from the task board. Bugs were assigned to devs but we ate this as part of the velocity.

              But we never rewrote or treated bugs as Stories

              Jack
              www.agilebuddy.com
              blog.agilebuddy.com


              --- In scrumdevelopment@yahoogroups.com, "Sten" <steoj@...> wrote:
              >
              > No, I am not talking about bugs we create from the user stories that are completed during sprints. The team is configuring an Off-The-Shelf (OTS) product and in this way adjusting functionality that is already in the product, but also modifying and implementing new functionality by plug-in scripts and small chunks of code.
              > When there are bugs detected in the product (that is also under development, but handled by the supplier) we find our selves spending a lot of time testing new releases of the product, logging issues and bugs. We do have dates on when to expect new releases containing new and updated functionality from the supplier, and may therefore plan the testing a little up front by defining user stories.
              > How should we organize the work so that it is visible how much effort the bugs in the OTS product really demands?
              > Fixing bugs introduced by the external manufacturer wouldn't be value for the business, would it?
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.