In my previous blog articles, I discussed how limiting the number and size of things we are working on (aka Limiting WIP) can dramatically increase our throughput. This kind of lean thinking leads organizations to huge increases in the ability to get things done. Then I suggested a way of thinking of productivity as getting the most value for the work. This means it’s very important to know and keep updating value and size. I suggested a pretty quick and easy way to estimate value by using relative value estimation. In addition, I threw in a pretty common value framework to help look for value that matters. In this article, I will try to pull it all together by suggesting a way to set priorities that align with our productivity goal.

Most lean agile frameworks suggest using a priority setting technique called Weighted Smallest Job First or WSJF (pronounced WiSJiF). In its simplest form, this means doing the most valuable and smallest thing first. So if you have done the work to estimate size and value then your priority looks like this;

Priority = Value/Size (Wait what? You said that was the goal; Productivity. Oh I get it!)

So if you have a story with a relative size of 3 and relative value of 21 this will be a 7 priority score. A size 13 and value 21 will be a 1.6 priority score. This gives you a very quick way to sort the backlog with the highest priority (top of the backlog) having the highest score. There may be some ties but that’s fine. Scrum teams generally should plan from the top of the backlog. As the team pops work off the top, values and sizes may change so they need to be updated.

If your team is working on the top of the priority sorted list then you have assurance that they will be as productive as they can. This is because the low size if driving throughput and the high value is driving the usefulness of the throughput.

For bonus points, consider how urgency can be worked into your priority setting. Does the value evaporate? Is there a competitive or regulatory deadline? For situations like this, many organizations include a multiplier to the value estimate that functions to pop time critical work higher.

About now you lean thinkers start getting the Pareto itch. Well scratch it by burning up value and burning down work (or size). You may feel uncomfortable guessing that you have built most of the value for the effort so graph it; you have the data. If you can build 80% of the value with 20% effort why would you keep building?

Note that some agile frameworks get very complex about priority setting. SAFe for example uses cost of delay to make sure you are always working on the highest impact thing. I fine the most simple the better. Estimating value is estimating (aka prediction). Our ability to predict into the future is not good; even with sophisticated math, even though we have many experts hoping they can predict. In lean, its waste to try to meet an unattainable specification.  In other words; it’s not worth spending time trying to do what can’t be done. So my thinking is to do something really quick and cheap that gets us most of the way to what we need out of a prediction. That’s the thinking in extreme programming that lead to relative estimation using story points; and that’s why I suggest using relative estimation with value points. Just do it frequently, don’t spend a lot of time on it (each time) and don’t believe it (unless you solve time travel).

Here are some questions I hear;

Q: If we need to do it all (everything in the backlog) why do we need priorities? Why not FIFO (first in first out)? (Top 4 thoughts)

1. Because Agile is different. In Waterfall we set the wedding date, and then we introduce ourselves to our intended. In agile, we don’t take the plan as a commitment or a contract. We respond to reality as it happens. We rely on collaboration and trust with the team doing the work. In agile we kinda expect the PO and team to use their judgment about if everything is really needed. The track record in the industry is that about 80% of what we specify (predict) is never used or otherwise not needed. Somehow I think this time may not be different.
2. You can always keep building after you release. Why not take some risk out by seeing what the customer says?
3. What if your estimates are wrong and you run out of time or (any risk like losing a key person or the market changes or whatever)? Isn’t it better to have the most valuable parts done first?
4. FIFO is one of the top cause of scrum team velocity variation. There is great benefit in teams converging on a predictable velocity. This is a big topic that I’ll go into another time. Teams should not take items in the backlog as immutable contracts. Rather, stories as all levels of abstraction (features, epics, stories, and so on) are an invitation to a conversation. The team needs to balance the best value (to be productive) and size (to keep getting things done). Vertical splitting is the most valuable work of the planning.

Q: Why not just do the most valuable thing?

Because the most valuable thing may be so big it jams up throughput. Remember is the penny game when we passed one penny at a time we processed all ten coins in a third of the time it took to do the big batch of ten. Small is also better for quality. The impact and frequency of rework is much greater the bigger the pieces of work we accept. Testing is longer and more complex. Feedback is also harder to interrupt because the customer is reacting to the complexity of the bigness.

Setting priorities without understanding and considering size is like investing without considering return on capital or risk adjusted return. If you care about getting things done, you need to care about size.

Q: Why not just do the smallest to largest?

Because not all stories are equally valuable. What if you picked all the easy (or hard) stories and assumed those were all the valuable ones. You get 80% of the stories done and want to release to beat the competitor. I hope you were right. Most of the time, when I guess something by myself I’m not right. I do better when I take the consensus of my team. I do even better when I take the consensus of my team with the Product Owner.

Does this make sense? Thoughts?