This is a method for prioritization I created while running the Microsoft Kinect prototype project a number of years ago. Its purpose is to quickly and easily prioritize tasks for any type of project (although the description below assumes a typical software project). The basic method is to combine both the value of completing the task and the size of the task into a final priority value, which is then used to determine the rough order that tasks should be completed.
The Backlog
The first step is to compile a list of tasks: the backlog. This includes all tasks of any kind for the milestone/sprint you are prioritizing for. Tasks that you know aren't relevant for the current milestone/sprint do not need to be prioritized at this point, but they can still remain on the backlog for future milestones/sprint. These tasks can come from traditional user stories, but the method works regardless of how the tasks are added to the backlog.
Task Value
Each task in the list is given a value ranging from 0 to 5. While it may be a bit counter-intuitive, the lower the task value number, the more important the task is (you'll see why it needs to be this way in a moment). A task can only be assigned a value by someone who is in a position to understand how valuable it is. This is usually the product owner or director, but can be a producer, dev lead, art lead, etc. for some types of tasks. Be ruthless about what tasks are essential vs. what tasks are critical. Essential tasks are only ones that you will automatically slip a milestone for, and any team member should feel free to continually point this out to directors and producers.
- Value 0: Essential. If even a single one of these tasks is not completed, the milestone slips, even if that means the project will have to be canceled.
- Value 1: Critical. All of these tasks must be completed, but if just one or two aren't, then the milestone can still be met (although just barely, and it would usually be better to slip the milestone if possible).
- Value 2: High. All of these tasks should be completed, but realistically, some of them probably won't be. You would only slip a milestone if you had barely done any of these tasks.
- Value 3: Medium. These tasks certainly have value, and you should expect to complete at least half of them (mainly the small ones). You would never slip a milestone for these tasks, even if you did not do a single one.
- Value 4: Low. These are tasks you would like to get to, but are mainly just extra features and polish. You will likely end up doing the small ones, but that's all.
- Value 5: Minimal. These are tasks that are of questionable value or something that you don't want to leave off the list, but don't really expect to do. Often, none of these tasks are done at all, except for the tiny ones.
Task Size
Each task in the list is also given a size, based on the amount of time the task is estimated to take. This also determines how many "sprint points" the task is worth (these are explained below). A task can only be given a size by the person who would actually be performing the task, or by a consensus of the people who might be assigned the task. Producers and leads cannot tell a dev, artist, etc. how big a task is. Any task bigger than size five needs to be broken down into smaller tasks, especially if has lots of uncertainties or external dependencies (see below).
- Size 0: Tiny. Takes minutes to do. Worth a single sprint point for a half-dozen.
- Size 1: Extra Small. Estimated to take an hour or less. Worth 1 sprint point.
- Size 2: Small. Estimated to take two hours or less. Worth 2 sprint points.
- Size 3: Medium. Estimated to take three hours or less. Worth 3 sprint points.
- Size 4: Large. Estimated to take about four to five hours. Worth 5 sprint points.
- Size 5: Extra Large. Estimated to take about six to eight hours. Worth 8 sprint points.
- Size 6: 2XL. Estimated to take a day or more. Worth 12 sprint points.
- Size 7: 3XL. Estimated to take several days. Worth 20 sprint points.
- Size 8: 4XL. Estimated to take around a week. Worth 30 sprint points.
- Size 9: 5XL. Estimated to take around two weeks. Worth 50 sprint points.
- Size 10: 6XL. Estimated to take around a month. Worth 80 sprint points.
If a task has any significant uncertainty to it, the size is increased by one to three points. Note that inexperienced team members should usually have at least a point added for uncertainty to almost all tasks they are assigned. This also includes people new to the team, even if they are experienced.
- +0 for Uncertainty: Little to None. This type of task has been done many times before and is well-understood. Has very little chance of breaking anything.
- +1 for Uncertainty: Some. This type of task has only been done once before and/or has enough differences to add some uncertainty (different language, different platform, etc.), or might break something.
- +2 for Uncertainty: Lots. This type of task has not been done before, or the details are very different (functional language instead of imperative, mobile instead of PC, etc.), or is likely to break something.
- +3 for Uncertainty: Scary. There are multiple points of uncertainty, or it makes the team very nervous, or is likely to break something major and require significant refactoring and testing.
If the task has any significant external dependencies, the size is increased by one to three points.
- +0 for Dependencies: Little to None. This task is not dependent on anyone or anything outside the team. It also does not generate any unplanned work for anyone outside the team (test, art, legal, etc.).
- +1 for Dependencies: Some. Some part of the task cannot be completed without a small amount of work outside the team (this includes simple approvals). It could also generate some unplanned work for others.
- +2 for Dependencies: Lots. Major parts of the task cannot be completed without significant work outside the team (includes a difficult approval process). It could also generate major unplanned work for others.
- +3 for Dependencies: Scary. The task cannot be completed without deeply intertwined work with others outside the team (includes having a low likelihood of approval). It could also generate work for others which they might not be able or willing to do.
Task Priority
Now that every task has a value and a size, its priority is calculated by multiplying the two values together.
Priority = Value x Size
This gives all tasks a priority from 0 (highest priority) to 50 (lowest priority). What do these priorities roughly mean?
- Priority 0: These tasks either have to be done or can be done so quickly that they might as well be done. If necessary, sort these tasks by size if you want to know which one to do first.
- Priority 1-5: These should be the meat of the task list with all of the important tasks, and all of them should get done. If you miss any of these, you need to figure out why and prevent it from happening again.
- Priority 6-10: These are either not very valuable or would take a lot of time to do. In some cases, tasks in this range are just ones that haven't been broken down enough or need to have their uncertainties and dependencies reduced before they are worth prioritizing.
- Priority 11+: These are tasks you are not going to complete this milestone, as they are just not worth the cost, have too many uncertainties, etc. To get these tasks to actually be part of a milestone, they will need to be broken down further, and have their uncertainties or dependencies reduced.
Generally, tasks should be done in priority order. However, it is important to be flexible here, as some tasks may be dependent on others, some might be better to do at certain times, etc. The point is to heavily bias towards the higher priority tasks, not to use the priority list as an actual schedule.
Milestone/Sprint Planning
When planning for a milestone or sprint, use the "sprint points" (aka "story points") of each task to allocate a reasonable work-load for the milestone/sprint. Giving each team member 25 points worth of tasks for each week of work time devoted entirely to development generally works pretty well. Team members that can only work part-time on the project (including all students) should cut this amount in half. Note that every milestone should have a week's worth of planning, integration, testing, and review. This week cannot be counted as development time.
An example of how a milestone/sprint might be laid out (borrowed heavily from Paul Furio):
- 1st Week, Monday Morning: Plan the milestone/sprint. Review the backlog, determine the value and size of all relevant tasks, assign tasks as a team based on their sprint points. Must be finished before lunch. Should not take more than two to three hours
- 1st Week, Monday Afternoon through Wednesday Morning: Research, investigate, design, prototype, and talk to other teams. Reduce uncertainties and dependencies (or at least fully determine the nature of the dependencies). Do not do actual production work during this time.
- 1st Week, Wednesday Morning: Update the milestone/sprint plan. Remove and add tasks based on investigations. Update task sizes and reallocate based on new sprint point values. Must be finished before lunch, ideally takes an hour or less.
- 1st Week, Wednesday Afternoon: Begin real development for the milestone/sprint. Do daily stand-ups, track status on a sprint board, coordinate with other team members, etc. Continue focused work through Wednesday morning of the last week of the milestone/sprint. This should be at least two weeks, but could be three or four.
- Last Week, Wednesday Afternoon: Development stops for the milestone/sprint. Integration and full testing begins. No work that is not a bug fix or integration fix is allowed after this point.
- Last Week, Friday Afternoon: Right after lunch, the milestone/sprint is reviewed by the team. If everything is integrated, tested, and working, with no show-stopping bugs, then the team gets to party, play, go home early, etc. If not, work continues until the milestone/sprint is complete (even if that means staying late or working on the weekend). The team must take collective responsibility for completing the milestone/sprint, and not pretending that a build that kind-of works is acceptable.
Notes
This method attempts to strike a balance between efficiency and complexity. Part of why it works is because it is simple and not too rigid. It is easy to re-prioritize tasks if the situation changes, it can be done very quickly (which means you can actually get people to do it), and it doesn't force people to do things in an exact order (which means you can actually get people to follow it). The more "rigid" rules for milestone/sprint planning are there to make sure there is always allocated time between focused development to plan, investigate, test, review, etc. In this case, being rigid is good, because otherwise these critical non-development tasks get slowly squeezed out of the process, or planning and review starts taking more time than is warranted.
This method is obviously an "agile" development method, but I'm not too concerned about the exact language (milestones vs. sprints, sprint points vs. story points, etc.). Use whatever language works best for your team.