The insightfulness is a Must-have, and the specific formulation of the article is never the Must-have ;) I also validate that your Must-have is achieved :)
I suggest the article shows a miss understanding how goals, objectives, problem definitions and features interrelate E2E in larger companies with forward work plans. 50% of the solution may not be on your backlog. Don't re-contextualize. Rather learn the prior works first. For instance, If tactical staff are re-doing research and re-contextualizing priority without understanding indicators picked to derive "a must" ... these 2nd order staff should be fired. There are must have units of work but they are onlya must because the outcome or problem being solved requires them to achieve success decided normally by a larger pool of impacted parties than one project team. A must is not a subjective wishy-washy thing in most organizations and is core to contracts, service agreements, sign off artefacts and other aspects beyond a simple tactical decision. A Must is globally understood in a way that story mapping, MVP's and single order priority lists are not.
I'm fully aware of how larger organizations work and your perspective fits with what I see at these companies.
And yes, that will help cover up the lack of context, autonomy and collaboration, because you're stuck in the must-have coordination paradigm.
And what I've seen, even in larger organizations, that the must-have stops being a must-have as they discover how much more work the whole thing represents.
So in the end, yes, it's a suboptimal duct tape solution for larger solutions. It's perhaps better than not doing it but by doing it you are likely to do no better than mediocre.
This was an insightful read.
Thanks for letting me know, much appreciated, that's what we hope for when we publish something! <3
The insightfulness is a Must-have, and the specific formulation of the article is never the Must-have ;) I also validate that your Must-have is achieved :)
I suggest the article shows a miss understanding how goals, objectives, problem definitions and features interrelate E2E in larger companies with forward work plans. 50% of the solution may not be on your backlog. Don't re-contextualize. Rather learn the prior works first. For instance, If tactical staff are re-doing research and re-contextualizing priority without understanding indicators picked to derive "a must" ... these 2nd order staff should be fired. There are must have units of work but they are onlya must because the outcome or problem being solved requires them to achieve success decided normally by a larger pool of impacted parties than one project team. A must is not a subjective wishy-washy thing in most organizations and is core to contracts, service agreements, sign off artefacts and other aspects beyond a simple tactical decision. A Must is globally understood in a way that story mapping, MVP's and single order priority lists are not.
I'm fully aware of how larger organizations work and your perspective fits with what I see at these companies.
And yes, that will help cover up the lack of context, autonomy and collaboration, because you're stuck in the must-have coordination paradigm.
And what I've seen, even in larger organizations, that the must-have stops being a must-have as they discover how much more work the whole thing represents.
So in the end, yes, it's a suboptimal duct tape solution for larger solutions. It's perhaps better than not doing it but by doing it you are likely to do no better than mediocre.
Using "Min Specs" from Liberating Structures would be a good alternative to MoSCoW where everything is considered, but items are eliminated.