Work item prioritization
This recipe is about the prioritization of work items in a backlog. There is some confusion as to the meaning of the term priority. Priority is a ranking of when some task should be performed with respect to other tasks. There are a variety of factors that determine priority and different projects may weigh such factors differently. The most common factors influencing priority are:
- Cost of delay – the cost of delaying the performance of the work item, which in turn is influenced by:
- Criticality – the importance of the completion of the work item
- Urgency – when the outcome or output of the work item completion is needed
- Usefulness – the value of the outcome of the work item to the stakeholder
- Risk – how the completion of the work item affects project risk
- Opportunity enablement – how the completion of the work item will enable stakeholder opportunity
- Cost – what is the cost or effort needed to complete the work item?
- Sensical sequencing – what are the preconditions of the work item and what other work items depend upon the completion of this work item?
- Congruency – consistency of the work item to the mission of the iteration to which it is assigned
- Availability of resources – what resources, including specialized resources, are needed to complete this work item, and what is their availability?
Some priority schemes will be dominated by urgency while others may be dominated by criticality or resource availability. The bottom line is that work item priority determines which iteration a work item will be allocated to from the project backlog and to a lesser degree when, within an iteration, the work item will be performed.
Purpose
The purpose of work item prioritization is to intelligently plan the work so as to achieve the product goals in an incremental, consistent fashion. Specifically, the goal of work item prioritization is to allocate work items to the iteration backlogs well.
Inputs and preconditions
The product backlog has been created.
Outputs and postconditions
Work items in the product backlog are prioritized so that iteration planning can proceed.
How to do it
There are many ways to prioritize the backlog. Some, such as the MoSCoW method, are qualitative. Must, Should, Could, Won’t prioritization as described in the International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge (BABOK) Guide, www.iiba.org/babok-guide.aspx. In this approach, work items are categorized into the following four groups:
- Must: A requirement that must be satisfied in the final solution for the product to be considered a success
- Should: Represents a high-priority work item that should be included in the final solution if possible
- Could: A work item that is desirable but not necessary for success
- Won’t: A work item that the stakeholders have agreed to not implement now, but might be considered in a future release
Priority poker is another means by which priority may be assigned. Priority poker is similar to planning poker used for the estimation of work item effort. Planning poker is discussed in more detail in the Estimating effort recipe and so won’t be discussed here.
This recipe outlines the user of a prioritization technique known as Weighted Shortest Job First (WSJF) as defined by the Scaled Agile Framework (SAFe), see www.scaledagileframework.com/wsjf. The basic formulation is shown below.
The SAFe definition of the cost of delay is provided in the equation below. This equation differs from the original SAFe formulation by adding a project value term.
Business value is either critical or useful to the stakeholders or some combination of the two. Project value, the term I added to the formula, refers to the value of the project. For example, the reduction of technical debt may not add direct value to the stakeholders but does provide value to the project. Time criticality, also known as urgency, refers to when the feature provides value to the stakeholder. Risk reduction is the improvement in the likelihood of project success, while opportunity enablement refers to business opportunities, such as new markets, that a feature will enable.
Each of the aspects of the cost of delay is scaled using values such as the Fibonacci sequence (1, 2, 3, 5, 8, 21, 34, 55, 89, 144, and so on) with larger values indicative of a higher cost of delay. Since these are all relative measures, the summation provides a good quantitative idea of the cost of delay. For a given job size, a higher cost of delay results in a higher priority. For a given cost of delay, a larger job size reduces the priority.
Job duration is difficult to estimate until you know the resource loading, so we normally substitute Job cost for Job duration. Job cost is the topic of the Estimating effort recipe. WSJF does a good first stab at determining priority, but it needs to be adjusted manually to take into account congruency with iteration missions and specialized resource availability. The workflow is outlined in Figure 1.26:
Figure 1.26: Work item prioritization
Select the next work item from the backlog
Starting with the first work item, select the work item to prioritize.
Estimate the job cost
Estimate the cost of performing the work item. The details of how do to this are discussed in the Estimating effort recipe.
Estimate the business value
Whether you are considering the criticality of the work item or its usefulness of the work item, or both, estimate its business value. For this and the other estimates contributing to the cost of delay, we are using relative measures with a Fibonacci sequence with the higher values corresponding to greater business value. Work items of similar business value should have the same value here.
Estimate the project value
The project value is the value that the completion of the work item brings to the project, such as the completion of a technical work item or paying down technical debt.
Estimate the time criticality
Estimate the time criticality of the work item, with more urgent work items having a higher value.
Estimate the risk reduction or opportunity enablement value
Estimate either the reduction of project risk or the enablement of business opportunity since the approach of the previous to steps. Greater risk reduction or greater opportunity means higher value.
Compute the Cost of Delay (CoD)
Compute CoD as the sum of the business value, project value, time criticality, and risk reduction.
Compute the weighted shortest job first
Compute WSJF as the cost of delay divided by the job cost.
Group similar priority items into the iteration backlog
The backlog for each iteration should contain elements of the same priority, depending on the availability of resources to perform the work. If there is capacity left over after allocating all elements of the same or similar priority, add work items from the next lowest priority. Similarly, if the accumulated cost of the set of work items of the same priority exceeds capacity, then move some to the next iteration backlog.
Adjust work item priorities to account for iteration missions
Examine the work items for congruence with the mission of the iteration. If there is no congruence, then is there another iteration where the work item is more in line with the iteration purpose? If so, adjust the priority to match that of the more relevant iteration.
Adjust work item priorities to adjust for any needed specialized resources available
Are there specialized resources needed for the completion of a work item? This might be the availability of a Subject Matter Expert (SME), or the availability of computational or lab resources. Adjust the priority of work items to align with the availability of resources needed to accomplish the task.
Populate iteration backlogs with items of similar priority
Once the priorities have stabilized to account for all concerns, populate the iteration backlogs with the work items.
How it works
Prioritization is the ranking of elements on the basis of their desired sequencing. There are many means for prioritization with varying degrees of rigor. I prefer the WSJF approach because it takes into account most of the important aspects that should affect priority, resulting in a quantitative measure of the cost of delay divided by the size of the job.
Figure 1.27 shows a graph of WSJF isoclines. All curves show how the resulting value of WSJF changes as job size increases. Each separate curve represents a specific value for the cost of delay. You can see that the priority value diminishes rapidly as the size of the job grows. The practical effect of this is that higher-cost (i.e., higher-effort) tasks tend to be put off until later.
Just be aware that this is a bit problematic; since they require multiple iterations, there will be fewer iterations in which to schedule them:
Figure 1.27: WSJF iscoclines
While this method is recommended by the SAFe literature, in actual practice it must be modified so that you have congruence with the missions of the iterations. For example, it could happen that providing an encrypted message transfer has a high WSJF value while the creation of the base protocol stack is a lower value. Nevertheless, it makes no sense to work on the encryption design before you have a protocol in place over which the messages can be sent. Thus, you would likely raise the priority of the creation of the protocol stack and lower the priority of the encryption work to get “sensical sequencing.” Encryption math can be quite complex and if the encryption subject matter expert isn’t available for Iteration 6 but is available for Iteration 8, then it makes sense to adjust the priority of the encryption task to implement it when that expertise is available.
Example
Table 1.11 shows a worksheet that has a number of different kinds of work items, their previously estimated effort (job size), and the CoD terms. The spreadsheet sums up the terms to compute the Cost of Delay (CoD) column and then the WSJF shows the computed Weighted Shortest Job First.
The next column is the adjusted priority. This priority is generally the WSJF value but some of these are adjusted to move the work item into an appropriate iteration. The last column shows in which iteration a work item is planned to be resolved:
|
Work item type |
|
|
Cost of delay terms |
|
|
Priority |
|
||||
Epic |
Work item use case |
Work item user story |
Spike or technical work item |
User business value |
Project value |
Time criticality |
RR | OE |
CoD |
Job size (user story points) |
WSJF |
Priority |
Planned Iteration |
|
|
|
Spike: Team availability |
1 |
55 |
1 |
21 |
78 |
2 |
39.00 |
39.00 |
0 |
|
|
|
Spike: Aggressive schedule |
1 |
1 |
34 |
34 |
70 |
3 |
23.33 |
23.33 |
0 |
|
|
|
Spike: Agile MBSE impact |
1 |
34 |
21 |
13 |
69 |
3 |
23.00 |
23.00 |
0 |
Resist |
Control resistance |
Provide basic resistance |
|
55 |
1 |
21 |
1 |
78 |
55 |
1.42 |
1.42 |
1 |
|
|
|
Spike: Motor response lag time |
8 |
1 |
1 |
1 |
11 |
8 |
1.38 |
12.00 |
1 |
|
|
|
Spike: Robustness of main motor |
34 |
1 |
1 |
34 |
70 |
5 |
14.00 |
14.00 |
1 |
Set up physical bike |
Set up bike fit |
Adjust seat height |
|
13 |
1 |
13 |
13 |
40 |
3 |
13.33 |
13.33 |
1 |
Set up physical bike |
Set up bike fit |
Adjust seat reach |
|
13 |
1 |
8 |
13 |
35 |
3 |
11.67 |
11.67 |
2 |
|
|
Calibrate power output |
|
8 |
8 |
21 |
1 |
38 |
8 |
4.75 |
10.00 |
2 |
Emulate gearing |
Emulate front and rear gearing |
|
|
34 |
1 |
21 |
1 |
57 |
34 |
1.68 |
19.00 |
2 |
Emulate gearing |
Emulate mechanical gearing |
|
|
21 |
1 |
21 |
1 |
44 |
34 |
1.29 |
10.00 |
2 |
Emulate gearing |
Emulate basic gearing |
|
|
34 |
1 |
34 |
1 |
70 |
89 |
0.79 |
10.00 |
2 |
Set up physical bike |
Manually adjust bike fit |
|
|
34 |
1 |
21 |
1 |
57 |
13 |
4.38 |
4.38 |
3 |
Set up physical bike |
Set up bike fit |
Adjust handlebar height |
|
8 |
1 |
1 |
3 |
13 |
3 |
4.33 |
4.33 |
3 |
Set up physical bike |
Set up bike fit |
Adjust handlebar reach |
|
5 |
1 |
1 |
3 |
10 |
3 |
3.33 |
3.33 |
3 |
Monitor ride metrics |
|
Monitor power |
|
34 |
1 |
1 |
1 |
37 |
13 |
2.85 |
2.85 |
3 |
Monitor ride metrics |
|
Monitor speed |
|
21 |
1 |
1 |
1 |
24 |
5 |
4.80 |
4.80 |
3 |
Monitor ride metrics |
|
Monitor distance |
|
21 |
1 |
1 |
1 |
24 |
5 |
4.80 |
4.80 |
3 |
|
|
|
Spike: USB robustness |
21 |
8 |
1 |
8 |
38 |
5 |
7.60 |
7.60 |
3 |
Monitor ride metrics |
|
Monitor cadence |
|
8 |
1 |
1 |
1 |
11 |
5 |
2.20 |
2.20 |
4 |
Communicate with apps |
Communicate with low-power Bluetooth |
|
|
55 |
1 |
8 |
1 |
65 |
34 |
1.91 |
1.91 |
4 |
Set up physical bike |
Set up bike fit |
Select crank length |
|
2 |
1 |
1 |
2 |
6 |
5 |
1.20 |
1.20 |
4 |
Resist |
Control resistance |
Set resistance under rider control |
|
13 |
1 |
5 |
1 |
20 |
21 |
0.95 |
1.00 |
4 |
Configure bike for rider |
Connect personal data to app |
|
|
13 |
1 |
1 |
1 |
16 |
21 |
0.76 |
1.00 |
4 |
Set up physical bike |
Estimate bike fit with external parameters |
Compute fit from professional fit data |
|
3 |
1 |
1 |
1 |
6 |
1 |
6.00 |
0.50 |
5 |
Monitor ride metrics |
|
Monitor incline |
|
13 |
1 |
1 |
1 |
16 |
8 |
2.00 |
0.50 |
5 |
Communicate with apps |
Communicate with ANT+ |
|
|
34 |
1 |
5 |
1 |
41 |
34 |
1.21 |
0.50 |
5 |
Communicate with apps |
Communicate with ANT FEC |
|
|
34 |
1 |
13 |
1 |
49 |
55 |
0.89 |
0.89 |
5 |
Set up physical bike |
Estimate bike fit with external parameters |
Load GURU bike fit data |
|
5 |
1 |
1 |
2 |
9 |
13 |
0.69 |
0.69 |
5 |
Set up physical bike |
Estimate bike fit with external parameters |
Load trek bike fit data |
|
5 |
1 |
1 |
2 |
9 |
13 |
0.69 |
0.69 |
5 |
Resist |
Control resistance |
ERG mode |
|
21 |
1 |
1 |
1 |
24 |
55 |
0.44 |
0.30 |
5 |
|
Manage personal data |
|
|
21 |
3 |
2 |
1 |
27 |
5 |
5.40 |
0.30 |
6 |
Set up physical bike |
Predict bike fit with camera image |
Access camera image |
|
5 |
1 |
1 |
1 |
8 |
2 |
4.00 |
0.30 |
6 |
Set up physical bike |
Predict bike fit with camera image |
Retrieve road bike dimensions from camera image |
|
8 |
1 |
1 |
1 |
11 |
5 |
2.20 |
0.30 |
6 |
Set up physical bike |
Predict bike fit with camera image |
Compute fit parameters from road bike dimensions |
|
1 |
1 |
1 |
1 |
4 |
2 |
2.00 |
0.30 |
6 |
Resist |
Control resistance |
Set resistance under external control |
|
21 |
1 |
5 |
1 |
28 |
39 |
0.72 |
0.30 |
6 |
Emulate gearing |
Emulate DI2 gearing |
|
|
13 |
1 |
5 |
1 |
20 |
55 |
0.36 |
0.30 |
6 |
Table 1.9: Prioritized work items