Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
sprint story list doesn't handle "what's the next bug to work on" use case well #75
We sort the sprint story list by priority in order to figure out what bugs to work on next. However, this has two problems:
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:
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:
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?