sprint story list doesn't handle "what's the next bug to work on" use case well #75

willkg opened this Issue Sep 5, 2012 · 0 comments


None yet
1 participant

willkg commented Sep 5, 2012

We sort the sprint story list by priority in order to figure out what bugs to work on next. However, this has two problems:

  1. resolved bugs show up sporadically in the list
  2. blocked bugs show up sporadically in the list

The first set of bugs are denoted by a light green background and RESOLVED in the status field on the far right.

The second set of bugs have a BLOCKED tag in the summary.

This isn't conducive to scanning the list for bugs that are ready to be worked on in order of priority (or actually--any non-status ordering) without doing a lot of extra work. This isn't a big deal at the beginning of the sprint, but becomes a big deal at the end.

So, to clarify, one of the important use cases of the sprint story list page is this:

Bob is a developer and wants to know what bug to work on next.
He looks at the story list for the current sprint, sorts by priority, and looks for the first
non-resolved non-blocked bug listed.

I'd like to minimize the time wasted parsing out the bugs that don't fit this use case which increases as the sprint gets close to the end.

One idea I had was to break the sprint story list into three groups:

  1. stories that are ready to be worked on
  2. stories that are blocked
  3. stories that are resolved

Is that something that works for all use cases for the sprint story list page? If not, then should we have different views of the page? Maybe multi-column sorting would be good enough? Maybe toggle buttons for showing/hiding blocked bugs, resolved bugs, bugs that are ready to be worked on?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment