Difference between revisions of "StoryBoard/Priority"
| Line 1: | Line 1: | ||
| − | This page tracks various approaches we could take for prioritization. | + | This page tracks various approaches we could take for prioritization for tasks inside of stories. |
== User stories == | == User stories == | ||
| Line 16: | Line 16: | ||
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. | 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 === | === Ranking, instead of discrete levels === | ||
| Line 24: | Line 23: | ||
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. | 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. | ||
| − | |||
== Issues == | == Issues == | ||
tbd | tbd | ||
Revision as of 16:48, 13 February 2014
This page tracks various approaches we could take for prioritization for tasks inside of stories.
Contents
User 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
Implementation
Simple priority
A single discrete field with 3-5 levels:
- Critical/High/Med/Low
- MoSCoW model (must have, should have, Can have, Won't have)
Parallel priorities
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.
Multi-dimensional priorities
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.
Issues
tbd
