Prioritization is arguably the most important thing in Scrum, as Scrum is about incremental delivery in order to provide value and feedback. In a nutshell, prioritization determines the order in which the value is produced, and thus drives what feedback is sought.
We use a layered approach to prioritization, taking into considerations Items being moved from the Inbox up through the Backlog to be Done. Our first rule of 3 is the three layers of prioritization:
1. First Layer
The first layer of prioritization determines whether or not an Item is in scope for consideration for the current release. If it is, then the Item is moved to the Fridge as part of the Backlog.
2. Second Layer
The second layer of prioritization determines whether or not the Item will be worked on ‘soon’ or not. If it is, then the Item must be moved to the Back Burner to be refined and the result will be Ready Stories in the Back Burner, ready for Planning.
3. Third Layer
The third layer of prioritization determines whether or not the Ready Story is going to be worked on ‘now’ or not. This is done as part of Planning or, more rarely, as an adjustment to an existing plan. If it is to be worked on now, the Story’s Agreement is finalized and agreed to by the Team, and the Story is accepted into the Front Burner to be Done and delivered.
The 3 layers of prioritization are the same regardless of what the Scrum Team is developing. However, overall prioritization strategies differ based on the main goals of the Team. Continuing with our Rule of 3, there are 3 goal-driven Team prioritization strategies:
1. Continuous Improvement
A Continuous Improvement strategy is primarily for Teams doing Maintenance or providing features on an opportunistic basis; there is little (or no) long-term strategy to be considered when prioritizing.
2. Defined Feature Delivery
This strategy is used when the Team has a fixed set of Features to deliver, often on a given date. The Goal of this strategy is to get all the Features across the finish line to be minimally releasable at the time of Release. This focus is constant and paramount in all prioritization efforts.
3. Fuzzy Feature Delivery
This is the “I don’t know what I want, but I’ll know it when I see it,” type of delivery. When done well, it usually turns into a series of (internal) Defined Feature Delivery Releases, as the necessary Features make themselves known. When done poorly, it could turn into a Continuous Improvement Delivery, with everybody hoping that there will be a successful endpoint.
Is prioritizing one of you priorities? We’ve got training for that.
As Always, Stay Agile.