Diesen Artikel auf Deutsch lesen

The problem with prioritizing discrete sequences

As a general rule, tasks and work should be prioritized before they are processed. However, as important as this is, no team should spend an eternity on it. If they did, tasks or work would never be finished. 

Some teams might intuitively think that creating a prioritization backlog is okay: they’ll sit down and decide that one task is more important than another, and that this other task is more important than the other.

To do this type of proritizing, teams might use a simple letter system: A, B, C, D, .... Or use numerical values between 1 and 10 or 1 and 100, and other similar linear approaches with a discrete order. Unfortunately, as soon as things get a bit complex, these approaches fail. 

Chaos ensues because team members could also then attach different values to the same task. Also you have to ask -  is there an average everyone conforms to? And if there is, is there objectivity in this compromise? Several parent tickets are prioritized, but what does the team do with the subtasks? Are they prioritized the same as the parent tickets? How do you put a severe backlog or a Jira project with hundreds of tasks into a sensible, practical order?

More granularity with WSJF

For large and more complex priorization cases, there are more suitable and proven methods that work, one of them being WSJF. In this abbreviation, W stands for “weighted", S for “shortest”, J for “job" (i.e. task or project), and F for being the “first” thing you should do.

This basically means: Do first what requires little effort, but still generates a lot of business value! This is what every team should strive to do. 

The WSJF approach was developed by Don Reinertsen. Its predecessor, "Shortest Job First", dates back to the 1970s, when computer resources were incredibly expensive, so teams had to weigh very carefully which jobs should be done first. Back then, it was the tasks with the shortest turnaround times. Don Reinertsen finally introduced this weighting priroization to software teams.

How does WSJF prioritization work in practice? Ultimately, it is not particularly difficult. Using WJSF, the team evaluates each task with regard to four dimensions and calculates a numerical value from this, the WSJF value. And this opens up the possibility of systematically forming a clear order - even with hundreds or thousands of tickets in the project or backlog.

Using four dimensions to calculate prioritization

The four dimensions are each assigned Fibonacci numbers. The first three dimensions determine the “Delay Cost”. They are made up of:

• User and Business Value: How do the customers or users (user value) and the company (business value) benefit from implementing this task?
• Time Criticality: Are there deadlines that need to be met? Are customers waiting urgently for the feature? Would the user and business value be the same if the implementation were delayed?
• Risk Reduction and/or Opportunity Enablement: Would the implementation reduce an existing risk? Or would new opportunities arise, for example through additionally gained technical know-how?

In order to quantify the extent of these dimensions, the team uses a (mostly modified) Fibonacci scale, which usually consists of the values 1, 2, 3, 5, 8, 13, 20, 40 and 100. Fibonacci numbers are therefore practical and useful because the distances get steadily larger between values. This fits well with the problem of complexity estimation: tasks that the team can estimate relatively accurately can be well differentiated with the lower values (1, 2, 3, 5, 8, 13). The higher values, in turn, show large gaps (20, 40, 100). In this respect, the approach encourages breaking up larger works into smaller parts, which in turn can be better assessed. 

By the way: Fibonacci numbers do not have any real value -  they represent relative ratios. So they should not be used to represent, for example, monetary costs or working hours.  

Overall, to quantify the delay cost, the three assigned estimates should then be added together.

Finally, the fourth dimension in determining the WSJF is Job Duration, i.e. the expected effort to or duration of implementation. Here, too, Fibonacci numbers are used (and again not to quantify concrete time expenditures, but as a relative ratio).

The WSJF is now calculated by dividing the Delay Cost by the Job Duration.

The higher the WSJF value, the higher the task is prioritized. So in the example below, Task B has a higher priority than Tasks A and C.

WSJF in Jira

Now it would be handy to be able to work with the WSJF method directly in Jira, wouldn't it? Well, that's possible! The new Jira app Awesome Custom Fields makes assigning WSJF values (and other tasks) a simple exercise. 

It enables teams to integrate WSJF queries into their processes via user-defined fields, i.e. custom fields.

The assigned WSJF value is clearly highlighted as a visual element in all tickets and is always transparent on appropriately configured boards.

Often custom fields are thought to be technologically complex and difficult to understand. But with Awesome Custom Fields, the custom fields in Jira are more accessible, understandable and easier to use. WSJF is by no means the only prepared custom field that the app comes with. It also has interactive progress bars, multi-user selection, star ranking, status tables, complexity estimates in T-shirt sizes, prioritization according to the MoSCoW method, and many more custom fields for common use cases for agile teams. More are added all the time.

The following short video gives a first impression of what is possible with the app. If you need to customize fields in your teams, it is definitely worth taking a second, closer look!

Awesome Custom Fields for Jira: Install now for free

Awesome Custom Fields is available for free on the Atlassian Marketplace - and it's just the beginning. The development team is working hard to implement more use cases and provide even more configuration options. Later this year, the team will deliver several additional features that will make working with custom fields even easier and more flexible at the same time, such as custom fields at the project level.

Do you have any questions? Want to know more about the status quo and the future of the app? Do you want certain use cases that are not yet available or planned in the app? Then get in touch: The team is looking forward to talking to you!

---

Further Reading

• The SAFe® Solution for Prioritization – WSJF Meets Jira
• Awesome Custom Fields: An Important Jira Feature Has Become More Accessible and Understandable
• 7 Tips To Get Your ITSM Teams Ready for On-call
• Is Jira trapped in your IT and development teams?
• More efficient business processes with Jira and Easy Issue Templates