Re: [scrumdevelopment] Re: Should issues and defects create user stories on the product backlog?
- On 3 December 2010 10:55, Sten <steoj@...> wrote: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.
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?
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
- 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
--- In email@example.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?