Which role creates tasks under bugs?

Do these tasks amount to a revision of the Sprint Backlog?

Yes. They are unplanned work which must be addressed before the next sprint.

For sure not the Scrum Master (see http://blog.scrum.org/who-is-the-professional-scrum-master/ which is a good article describing the role of SM)

I would say the PO, as he is responsible for ordering the PBI, which would include the bugs. He also knows best the business impact of the bug and thus the business value of fixing it. But he can delegate this work to the development team.

The tasks would then be created by the development team and SB updated accordingly.

Depending on the amount, complexity and priority of the bugs the team should organize how to deal with them. If there are not too many the team could evaluate the complexity/work amount and priority within the refinement sessions together with the PO or reserve a special time slot/story points every sprint or every day for doing this. The high priority bugs could be fixed within this reserved time slot and the others free to pull whenever the teams sees fit. And if the bug is faster fixed then “planning/evaluating” it, then create the task, fix it right away and set the task to done.

Since these tasks amount to a revision of the Sprint Backlog, and the Sprint Backlog is wholly owned by the Development Team, it is up to them to replan it accordingly. They are the ones doing the work.

Posted By Mark Richman on 25 Jun 2015 03:05 PM
My question is: Whose job is it to create tasks under bugs - the Scrum Master or the Product Owner?

When you say "task" are you referring to a PBI or to referring to tasks under a PBI?

Tasks under a PBI of type Bug. Not tasks which are direct children of PBIs.

For work in the current sprint, I would argue that bugs don't need to be created at all. But, that's what my team wants to do, and I can't win the argument. So, they open bugs against PBIs in the current sprint, then add tasks under those bugs.

The root cause is that testers and developers are 12 hours apart, and email is an ineffective way to communicate in-sprint defects. I would personally be fine using the PBI history for in-sprint defects, but others (i.e. manager types) want to see "what's broken" in the middle of a sprint. Not very scrummy, but it's what I have to work with.

Actually you meaning a story under a feature? In this case, if the bug is coming out of work what is in progress within the current Sprint, you don't have to create bug tasks for it. It means that the work is still not "done". If the team wants to have those bugs visible, the team can create tasks within the Sprint Backlog. The Sprint Backlog is owned by the Development team.

In your case if you have to deal with insights from managers, you can give the managers access to the Sprint Backlog, so they can only see what is happening.

If the bug is coming out of previous increment(s), it might be useful to create new PBI's (not tasks) and add them to the Product Backlog. It's the work for the PO to order the PB.

Jeffrey,

The issue is that the manager also acts as part of the team. As such, he steps out of his "team member" role and uses his position of authority to demand more "obvious" insights in the sprint backlog. Hence, the request to create bugs in the current sprint, instead of just looking at the board for unfinished WIP.

There is a secondary concern in that team members are no colocated. That is, a developer in the US and a tester in India. Communication is inefficient, so the team is looking for an efficient mechanism to communicate issues with the WIP in the current sprint. Too much gets lost via email, so they create Bugs in the current sprint for unfinished WIP.

I agree that bugs for previously completed work should be created as bugs on the product backlog for later grooming and planning.

- Mark