New forum(s) for tools like TFS?

Hi,
These are great questions, and highlight the need to be mindful when using a tool - so that you use it the way you want to; and are not coerced in to doing anything you don't think correct.
Most tools have a degree of flexibility in them.
When do you create a bug
I suggest that you should create a bug only when you absolutely have to, and aim for finishing a sprint with zero (0) bugs. So create a bug when:
1. It is found in an environment outside of the Sprint (Live)
2. You need to remember what you were up to for the next day, or after the weekend
3. It is too much work to fix within your Sprint, and the Product Owner accepts the rest of the PBI apart from the bug

After that, the bug is a special form of PBI.
So you create tasks that are necessary to get it to "Done" and track it as you would any other work.

Regards
Simon

> When a bug is found for a PBI on the current sprint, do we need to add a bug item or a new task for the PBI, etc. etc.

No, you need to fix the bug and find out how it arose and how long it was there before it was detected. Then you can potentially improve your process.

The leanest way to handle this is to prioritize an in-sprint defect fix before any other Sprint Backlog items are progressed. That's the spirit behind the "andon" system and single piece flow. What you *don't* want is an in-sprint defect tracking system, as that just supports the accumulation of waste - a queue of rework, as the Poppendieck's have put it. When a defect is identified for work in progress, the best thing to do is to immediately fix it so depreciation and technical debt are minimized.

You can raise in-sprint defects as tasks against a story if you like, as long as you don't turn the Sprint Backlog into some sort of register of accumulated rework for future actioning.

As Simon points out, defects discovered after an increment has been accepted are effectively new PBI's. They should be triaged to the Product Backlog for prioritization by the Product Owner.

Thanks for the answers.

I had a discussion with the QA manager of our organization. He wants that testers add Bug items and not Tasks to the Sprint Backlog, when a bug is found for PBI of the Sprint Backlog.

My manager tries to find a compromise and suggests defining a custom work item in TFS to register a ‘BugTask’, the same as a task but used to register bugs for PBI’s that have no unfinished development tasks.

In my opinion PBI’s on the Sprint Backlog are not Done before the Product Owner declares that they are done in the Sprint Review meeting. That means no bugs can be reported for PBI’s on the Sprint Backlog before the Sprint Review meeting. Is this right?

Hi Franck,
I think the main problem here is that your development team doesn'nt own its process. Instead, you have an external QA manager, who obviously needs some help in understanding the difference between a sprint in Scrum and a testing phase in waterfall.
What is the reason he wants the testers to create bugs? Are they not part of the team, maybe not even in the same building, so he thinks a tool works better than individuals and processes? You should include them into the team in that case. The next step would be to have developers write tests while developing (or even before). There is no such thing as a tester in Scrum ;)