Using An Old Friend To Graphically Balance Value, Scope and Deadlines
In Specific and General Prioritization I described a real world prioritization scheme which ranked features (or more generally, items) by importance while recognizing two kinds of benefit: those for a general audience, and those demanded by specific stakeholders. At the same time, you also can’t ignore deadlines that mess with your existing priorities, and you ought not ignore scope.
Scope
Scope is obviously used in sprint planning and in determining road map capacity. Combined with a measure of feature value, you can obtain a “value-to-scope” ratio and then prioritize features according to this ratio; this is basically how the RICE framework works. For example, a feature that has $10M estimated revenue at an estimated cost of $500K provides a wonderfully concise ratio of 20, which would naturally beat out another feature with a ratio of 10.
While it would be lovely to always have real numbers and clean ratios, that’s often not possible. For example, an internal platform may not generate revenue. I’ve been happy with just “Nice To Have”, “Pain Point” and “Critical” as a numerator (my alternative to MosCow) and t-shirt sizing as a denominator in the value-to-scope ratio. You can further grade the labels above, for example, “Pain Point-” can be a minor nuisance while “Pain Point+” can be severe.
The qualitative buckets above are not necessarily ordinal because these buckets aren’t capturing value but rather, levels of criticality. Critical features will usually take precedence over Nice To Haves or even Pain Points. Despite this, value-to-scope ratios remain a useful currency both within a specific bucket and also at the margin between levels of criticality. For example, a low scope Nice To Have+ may outrank a high scope Pain Point-.
The diagram above is simplified, as value-to-scope ratios will vary in both value and scope. For instance, a cheap Nice To Have+ might outrank an expensive middle of the road Pain Point.
Deadlines
A stakeholder may ask for a feature that bypasses prioritization. Perhaps they need something from your team to enable their own project’s launch. An ask like this often comes with a deadline that is going to disrupt your priorities. Bottom line? There’s a fourth, non-negotiable bucket:
- Nice (or Should)
- Pain Point (or Could)
- Critical (or Must)
- Because I Said So!
The Less Important Stuff
If we are always busy with non-negotiable stuff, Critical stuff, Pain Points, and the occasional Nice To Have, when are we going to get all the lesser work done? The answer is obvious for those of you that have managed a feature queue: later or never. As items get delayed, new information may clarify features’ value, scope, or even criticality, causing them to be re-prioritized upwards or downwards.
Another obvious point that I’ll make just for completeness is this: how do you fit lower priority work into your plans? Packing luggage into a car, you know that the bigger stuff generally goes in first and dictates where the little stuff should go. The same is true of items that don’t fit into your regular planning. During periods of lesser workload, staff can attend to smaller tasks, often taking advantage of breaks between larger assignments. These tasks could venture beyond features, to things like tech debt and other housekeeping duties. Mixing in less critical items is good for developing less experienced members of your team, and giving even experienced developers some variety. In fact, your engineering lead will usually be making these tactical assignment decisions.
Integrating Value, Scope and Deadlines
The Gantt chart permits a unified treatment of scheduled items, ordering of items’ implementation by value, accounting for their scope in the form of task lengths, and allotment of spare time into less critical items.
I chose to simplify the above chart by just referring to items’ criticality and assuming duration as a proxy for scope. You can also embed the value-to-scope ratio directly into these tasks. For example, any given line can be divided by its t-shirt size, for example, “Pain Point + / 1”.
Conclusion
This article’s goal was truly about how to balance value, scope and deadlines. It just so happens that Gantt charts are ideal.
The Gantt chart helps the team visualize and better plan the project timeline. Agile teams may use the Gantt chart as a communication and coordination tool, helping stakeholders understand the project’s progress and upcoming activities.
However, the Gantt chart should be treated as a flexible reference rather than a rigid project plan. It is subordinate to what is learned while building. The product manager also can only facilitate putting together the plan — primary input is from engineering, because they’re the ones largely on the line for carrying it out. With flexibility and team involvement, Gantt charts actually do play well with agile.
