Agile development teams forge user journeys, personas, user stories, requirements, and features into backlogs.
Then some magic happens, and with the help of the product owner, some of those backlog items materialize into reality. A great job is done, and everybody is happy and moves on to the next job.
I want to take a more in-depth look at the somehow vague process of triage on the backlog of an MVP. I do not like the word Prioritization because it is too much linked to priorities (plural), and I think there is always one priority possible at the same time.
For a typical product manager triage translates to pain. We are permanently being torn apart between ideal product strategy and dead boring urgent quick wins from low hanging fruits. Triage or as far as I am concerned Prioritization is a tricky, painful task! I am also not a big friend of quantified approaches as the Prioritization Matrix from the Six Sigma world. When you torture data long enough, it will confess everything you need! 😉
We POs give our very best to get the maximum for everybody, but it is impossible to make everybody happy. Miraculously even though many are so glad, everybody agrees to blame us at the end.
It is, therefore, in our very interest to moderate and communicate this process in the best possible way to get extraordinary results, but also to lower our pain.
User stories, story points, and epics are just not enough to get a backlog that sustains some heavy fire from some stakeholders.
The weak point I would like to address is the somehow isolated, greenfield view on the importance that typically leads to triage.
The Business Value is a significant first step, but how is it defined and how was it derived and calculated?
The Business Model Canvas, which is quite popular in the startup scene, is a great way to estimate and communicate business value from a bird’s eye view, but what when you are not working in a startup on the runway?
Reporting the ratio between innovation, evolution, and maintenance is also an excellent foundation to assure a little more change and lift-off from the operational runway.
My proposal is a slightly enhanced Business Model Canvas, that assures even more room for innovation, especially in more settled organizations with an established reporting culture.
The Extended Business Model Canvas links backlogs better to corporate strategy, as it considers the organizational operation. It keeps everybody on the same boat, and it helps us PMs or POs to better communicate and is smooth.
One caveat to keep in mind! This is no snake oil for the not-so-seldom situation, where the top sponsor from the stakeholder community has his very own agenda to survive the next report period. But it will most probably make the difference between programs and corporate strategy more visible.
I usually like to report the following KPIs:
Current backlog (with business value as the difference between size/complexity and effort/costs)
Breakdown of innovation vs. evolution vs. maintenance
The Extended Business Model Canvas for epics selected user stories or low hanging fruits
…and, this is how it looks like:
Extended Business Model Canvas
It has two additional boxes with a significant impact:
Contribution to strategy
This is a great tool to clearly distinguish between low hanging fruits (those are so low that they rot on the ground – for a reason).
Technical Debt
This helps to document the hack-level, that amount of hacking and a good indicator for the instability that is about to be built into the system (after all every system should be rebuilt from time to time, and some hacks may help to get this done earlier).
Not every user story or backlog item has to be linked to the Extended Business Model Canvas. It is enough it introduces the two additional boxes to support your reporting.
You get an instrument to do stuff that is against the strategy. From time to time, it is good to have a tool to allow tactical considerations to overrule strategy. However, it is crucial to track how far you deviate from the strategy.
You get an instrument to document the dirty hack level that will materialize as technical debt in the future that you do not want to be accountable for.
I have used this tool with some success in the past and would like to get your feedback and ideas on it…
cotoaga.net 