This page tracks various approaches we could take for prioritization for tasks inside of stories.
- PTL/Drivers want to communicate top release goals, and use that to prioritize review effort
- Release managers want to communicate expected features in the upcoming release, based on how likely they are to land
- Developers want to list tasks they care about and order them, to organize their work and prioritize their reviews
A single discrete field with 3-5 levels:
- MoSCoW model (must have, should have, Can have, Won't have)
Different groups should be able to express different priorities. There is at least one "official" priority (set by PTL/drivers) but other groups or people can set their own.
Ranking, instead of discrete levels
Using pure ranking lets you express finer preferences. However if you apply that to a list of thousands, you end up not ranking at all. So it's rather: a few ranks at the top, and a whole lot of unranked.
Kanban-style dashboards (think: Trello boards) let you have multiple columns and rank tasks in as many parallel stacks as you need. This lets you express complex priorities (gate-blocking bugs can appear on their own stack, feature work can appear on their own stack, etc.) which allows you to use context (GTD-style) to pick your next task. These type of view only works if you have a limited set. You shouldn't have your thousands of bugs appear in one of those columns.
We don't want priorities
Classic priorities are set by humans. They don't really work unless you triage everything. And then devs don't really look at them. High cost, little benefit.
We want worklists
We want to be able to create arbitrary lists of tasks. They would be sorted, so you could reorder them if ordering has a meaning in that particular list. Lists could be "tasks we want to complete in that milestone", "gate-blocking bugs", etc. There could be lists at project level, curated by the drivers of the project. there could even be mandatory lists (think "icehouse-3 targets"). And then anyone could have their own lists.
But we still want to triage bug reports !
While setting a priority for a blueprint is pretty useless, determining the impact of a bug *is* useful. Should we use tags for that instead ? "regression", "data loss" ?