Skip to main content

New forum(s) for tools like TFS?

Last post 07:40 am April 1, 2014 by Ludwig Harsch
4 replies
06:00 pm March 22, 2014

Is it possible to add a forum for “Scrum tools” with a sub forum for “TFS and Visual Studio”, or only one of these forums?

We are using TFS with the Scrum template and I’ve some questions. E.g. do we need “fix” and “test” tasks for every Bug item? 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.


03:57 am March 23, 2014

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


05:13 am March 24, 2014

> 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.


06:19 pm March 27, 2014

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?


07:40 am April 1, 2014

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 ;)


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.