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 would like to take a deeper look at the somehow vague process of triage on the backlog of a 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 visionary 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 really give our very best to get the maximum for everybody, but it is impossible to make everybody happy. Miraculously even though many are happy, 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 importance that typically leads to triage.
The Business Value is a great 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 birds 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 a good foundation to assure a little more innovation 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 corporate operation. It keeps everybody on the same boat, it helps us PMs or POs to better communicate and is really easy.
One caveat to keep in mind! This is no snake oil for the not-so-seldom situation, where the top sponsor from the stake holder community has his very own agenda to survive the next report period. But it will most probably make the difference between agendas and corporate strategy more visible.
I usually like to report the following KPIs:
- Current backlog (with business vale as difference between size/complexity and effort/costs)
- Breakdown on 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 great 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 rebuild 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 you feedback and ideas on it…