Which role creates tasks under bugs?

Last post 11:04 am July 1, 2015
by Mark Richman
8 replies
Author
Messages
03:05 pm June 25, 2015

We often get bugs reported that require attention prior to the next grooming or sprint planning meeting. These bugs live in our Product Backlog, and are moved into the current sprint if we can commit as a team to fixing them. (We're usually told to commit, of course.)

My question is: Whose job is it to create tasks under bugs - the Scrum Master or the Product Owner?

Perhaps my question is specific to TFS, and other ALM systems may behave differently. The pointy headed bosses want to make sure they can run utilization reports against tasks to see who's spending their time where.

03:31 pm June 25, 2015

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

03:36 pm June 25, 2015

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

03:13 am June 26, 2015

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.

07:06 am June 26, 2015

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.

12:10 pm June 26, 2015

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?

12:43 pm June 26, 2015

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.

07:46 am July 1, 2015

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.

11:04 am July 1, 2015

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