What Is Prioritized?

Work items are used to prioritize among others:

• enhancement requests and requirements at a level of abstraction appropriate for stakeholders prioritization, such as use cases and scenarios,
• project tasks, such as setting up required infrastructure,
• defects,

or any other work that needs to be prioritized. The Work Items List hence provides us with one place for prioritizing work. Prioritizing too small units of work may lead to analysis-paralysis.

Who Prioritizes?

Prioritization is done by the extended team. Here are some examples on how different team members contribute to the prioritization:

• Analysts collaborate with stakeholders to establish the initial priorities for work items to implement, such as features, use cases and scenarios.
• Architects collaborate with stakeholders and development team to identify the architecturally significant use cases and scenarios, and re-prioritizes these so the team understands what needs to be done to drive down technical risk and to progress the evolution of the product in a technically sensible fashion.
• Developers and Testers calls out (not decides) the priorities of defects relative to achieving iteration objectives.
• Project Managers facilitates (not decide) driving convergence on what the team should focus on when planning a project, planning an iteration, and managing an iteration to ensure smooth execution, and that the perspectives of all team members are properly heard. When the team cannot gain consensus in a reasonable time, the project manager has final say on the priority of work items to small to warrant the attention of the paying stakeholder(s).
• Stakeholders that pay for the application has the final say on what capabilities to prioritize.

When Do You Prioritize?

When you put in a new work item in a Work Items List, you should give it an initial priority. Priorities are always changing, and below we describe what (re-)prioritization is done when Planning a Project, Planning an Iteration, and Managing an Iteration.

Prioritizing When Planning a Project

When planning the project, see Plan Project, key features, use cases, and scenarios are prioritized and potentially assigned to iterations as a part of laying out the project plan and what should be done when. These prioritizes will be revised later on as iterations are planned.

When starting a project where we enhance an existing application, we may have an existing work items list from past projects and usage of the application. If this is the case, we go through the work items list to survey and re-prioritize existing work items, so we understand which to focus on.

Prioritizing When Planning an Iteration

When planning what to deliver for an iteration, see Plan Iteration, the team needs to balance what delivers immediate value to the stakeholders with mitigating risk, see Project Lifecycle. The chosen balance should be reflected in the iteration objectives, which are then driving further prioritization and assignments of work items to the next iteration. This exercise should be done by the entire team to reflect all key perspectives, such as technical (“doing A before B saves you time”), managerial (“we do not have anybody that knows that legacy application until next iteration”, or business (“this scenario is more important than that scenario”).

Prioritizing When Managing an Iteration

We recommend against expanding or changing the scope of an iteration, see Manage Iteration, since this will almost certainly lead to scope creep, and potentially confusion among the team what to work on. This means that as you can up with new enhancement requests, you should capture them to a work item, but not assign them to the current iteration.

During an iteration, you are developing and testing code. As you develop solution increments, you will find defects. In most cases, you will directly fix the defect since it is trivial, best done by you, and should be fixed now. Examples of such defects are the many problems you find as you implement your code using a test-driven development approach. In other cases, the defect should captured as a work item. This allows it to be prioritized, potentially developed by somebody else and at a different time. If a defect needs to be addressed to provide an iteration build of reasonable quality that addresses the iteration objectives, it should be addressed to the current iteration. Note that this is not a creep or change of scope, since it merely indicates that we need to fix something to deliver what we already committed to.

How Do You Prioritize

Prioritizing is the difficult balancing of frequently competing priorities. For more information on the art of prioritizing, see for example [COH05].