File Bug for not-completed Product-Backlog-Item?

1
votes

We are using TFS 2013 and the latest Scrum template. From my understanding, bugs and PBIs are at the same level in the backlog.

But how to handle bugs/issues, that are found during a sprint in a "ready-for-test" PBI?

When a developer finishes a PBI, he moves it in the Kanban-Board from "In Progress" to "Ready For Test".

Then our Testers test this PBI (user-story) using Microsofts Test-Manager. When they find an issue, the create a new bug. The advantage of doing so, is that we get a good documentation of the observed problem automatically in the bug work-item.

But from my point of view, it's not a bug. It's simply an unfinished PBI!

The main problem with this approach is, that it's cluttering up the Kanban-board and the backlog very quickly.

What is best practice in that case? Is there somewhere a guideline / whitepaper for this scenario?

Or maybe we are just using the Test-Manager in the wrong way?

3
tfsscrummicrosoft-test-managertfs-workitem
I'm voting to close this question as off-topic because this question is about project management; not software development. – Jim G.

3 Answers

1
votes

I completely agree that what you have is an unfinished PBI. Where I think things may be going wrong is when the developer effectively 'hands the PBI over' for testing.

Handover, or sign-off, or 'passing the baton' are unhelpful in an agile or Scrum way of working. I advise that focus should always be on moving a single PBI to done. Nothing else matters. Only when that PBI is done, should the developer start work on another PBI.

So, I'd encourage the developer to do whatever it takes to get the PBI tested immediately before he/she starts work on anything else. If any issues arise, the developer addresses it immediately. That way you avoid the situation you describe.

1
votes

Create a new task within the PBI. To me, a bug has to be found in 'done' work - while the story is in development, it is just another piece of development that needs to happen before the story is done.

(I have duplicated my comment into an answer as people seem to agree).

0
votes

We created a new type of work item called Story Bug, which is based on Task. That is a bug in a story to difference it from a regular bug found outside the work of a story.

We also created for it a slightly different workflow: new -> in progress -> bug resolved -> bug in QA -> done.

The QA opens the story bug in the new state. Then the developer moves it to in progress and when he Finnish working on it he moves it to bug resolved. Then the QA takes it and moves it to bug in QA where he checks that the bug was fixed. If the bug was fixed the QA moves it to done; if not he moves it again to new.