Visually highlighting current iteration's bugs on taskboard

[baseliners]

platform:
backlogs:
ruby:

Don't see a feature request for this in the list of issues here so adding it in. It would be useful to have some way to show/highlight (visually) the current iteration's bugs on the taskboard.. i.e. if a bug is found for a story, that bug can be logged under the story and it shows up as a bug instead of a task for that story (this latter part is already logged in issue #547). The items logged as bugs would be visually distinguishable from tasks (without this, it's harder to focus on the tasks when testing happens in parallel with dev and bugs get logged).

Currently, we can almost make it work by adding bugs (tracker name is set to "Bug") to a story and they do show up on the taskboard but it's hard to distinguish from tasks unless the bug is set to a priority of Immediate, Urgent, or High, in which case the priority shows up on the bug. A workaround would be to show the priority for all bugs irrespective of priority value so that the Normal, Low, etc. bugs would also have the priority be shown on them.. this assumes that Tasks are not assigned priority or have priority of Normal or lower. Hopefully there's a better solution.

[Vanuan]

What about bugs related to stories in closed sprints?

[Vanuan]

It's controversial how to handle bugs in scrum: http://www.infoq.com/news/2009/07/coping-with-bugs

I think bugs should be shown in the sprint backlog if they've escaped sprint. And if the bug is found in the current iteration's story, than it's indistinguishable from the task, imho.

[baseliners]

Tricky question.. the literature suggests that bugs in closed sprints should be considered as part of the backlog and treated just like a story/feature. But this isn't straightforward to implement in a system since most teams will have a tracker (such as "Bug," potentially with custom fields) for bugs and if you include that tracker as a story, then you end up getting the current sprint's bugs also show up as stories on the taskboard, cluttering things up and more importantly, not showing the relationship between a bug in the current sprint and the associated story in the current sprint.

One way to solve this is to look at the associations - if a bug is a child of a story (or child of a task of a story) in the current sprint, show it as a sub-item of the story in that story's row on the taskboard (essentially, just like a task, but visually different). Bugs from closed sprints would show up as stories (this also allows for having a task/bug associated with this bug-story in the current sprint).

Doing this in Backlogs -- multiple ways I can think of but cleanest might be to have a new tracker selection explicitly for bugs, which would behave as outlined above. Implementing this will (I think) require fixing the issue reported in #547 so that any child item of a story does not get set to Task automatically. Having a tracker selection just for bugs may not be general enough though as the last poster in #547 mentions the need for various types of trackers as sub-items of a task.. but maybe bugs is a concept that's universal enough that most teams will find this approach useful?

[monkeysan]

Very interested in this, since I love the plugin and am in the process of pitching the workflow to my team, but the current constraint that all children of stories are forced to the task tracker is a problem.

We don't use bug as a story tracker, because we don't typically make stories for individual bugs found in closed sprints; instead, we tend to group them into 'value buckets/themes' and create a story for the collection.

We don't use bug as a task tracker, because our task currency is 'task' and Backlogs only allows a single task tracker. (We definitely distinguish 'tasks' from 'bugs,' since they have very different data associated with them.)

In a perfect world, we'd be able to specify multiple task trackers as well as multiple bug trackers, with the obvious constraint that no tracker can serve both roles.

However, an intermediary (and more flexible solution for some) would be to relax the child-force-to-task-tracker mechanism so that it only forced the immediate children of a story tracker to the task tracker, rather than the current behavior, which seems to force all descendants of story trackers to become task trackers. Honestly, I don't see the case for forcing all descendants to task in the first place, but maybe I'm missing something.

Thanks again for your great work.

[retorquere]

You're missing the fact that everything under a story shows up on the task
board, and that the task board columns are the states the task tracker can
have. Allowing flexibility in what comes under a story makes the task board
immensely more complex to implement, since you'd have to show all columns
that are relevant to any task, where each individual column is at the
same time only relevant to an visually-unknown subset of the cards on the
task board; you'd have to enforce that cards cannot be dropped on an
invalid state for it's tracker while giving the user prima facie clues on
which columns go with which cards, where columns can and do belong to
multiple trackers; showing all these extra state columns also makes the
task board incredibly wide, which hinders glancing at the board to learn
the state of your project, which is the primary use for the board. If we
narrow that down to "only immediate children show up", that means if you
use issues under such tasks, the actually relevant part of your workload
remains hidden. If you think these issues and the multitude of others I
forgot to mention are trivial problems to solve, I will gratefully accept a
patch that addresses them.

There is currently some work being done in a separate branch to offer a
little more freedom for stuff under stories, but it as of yet fails the
majority of our testing suite, and is thus nowhere near ready for use.

[monkeysan]

Indeed I was missing the fact that all descendants of a story issue show up on the taskboard. In that paradigm, your point is very well taken and would, in fact, kill the workflow I am driving for.

It would be a nice option to be able to set the child depth for Backlogs so that, for example, if set, the following would occur:

• Only tasks that are immediate children of a story issue will be rendered on the Taskboard.

• The rb_issue_patch (or wherever this is happening) would only force to task those issues whose immediate parent is a story issue, rather than going all the way back to the root.

  At least, that's how I think I'd like to use the tool. I can imagine a 'render subtasks on Taskboard' checkbox.

For now, I see the only scenario to satisfy my story is to relate bugs to tasks rather than make them genuine subtasks. It's ugly because I lose batch operations (Redmine doesn't set related issues in batch 'Edit' view, for obvious reasons) and I lose the visual hierarchy in lists.

Thanks again