I am new to the blog so I have missed the earlier posts.
I’ll read them.

-Alexey

We’ve been promoting essentially the practice you define for organizing the content of releases.

1) prioritize based on value (and Kano can help with that)
2) use estimates to manage delivery by timebox, incorporating into each release
3) manage change against those timeboxes (estimate-reality disconnects, new/modified requirements, bugs to be fixed)

Prioritizing Requirements Across Releases and Prioritization With ROI and Utility make a good starting point – and there are other articles too. Let me know if you want me to add the links to this thread.

Thanks for this. I continue to enjoy your posts.

I have two comments on your topic;

One related to the irrational but important motivations associated with perception which I posted on Jeff’s oiginal article.

The other is about resourcing multiple projects. For instance you might have one implementation manager working across all releases and he or she will need to schedule them according to their ability to get through the work.

But in general your point is a good one. I am wroking with some marketing mangaers now who are launching products.

The ones that consider the launch date as critical are clearly sacrificing their business case by planning to launch a substandrd product which no one will buy, while the ones who put a quality product first are going to achieve their targets, just maybe a little later.

I am up for building the business case up-front before you
even start release implementation. How about spending a little
more time and effort at the release planning stage or even
as part of the backlog prioritization work (which may be
happening in background, parallel to release work), based on
customer feedback, risk and ROI estimates (the exact formula
is a topic for another discussion :] ).

Instead of traditional ‘must have’, ’should have’, ‘could have’
prioritization (where you might have N, M, and K features of
each sort) do exact 1,2,3,4,5,….. Where #1 according to your ROI
calculations and customer feedback analysis has the biggest weight
then #2 weight, then #3 weight, …. And then also decide
which # is the one before which you can not compromise.

Of cause collaboration with R&D is very important to keep yourself in check. May be all your team can do in a given time frame is just #1 and #2. Estimates wont solve all your problems but will definitely help you be more
realistic. Actually an experienced team doing its N’th incremental release can be pretty precise.

Then have your R&D team focus on the features in this exact order (which they actually agreed to during release planning collaboration).

In such a scenario when the ‘unexpected event’ comes or release is not meeting your deadlines at least you know you’ve done your best in terms of the most important features. The decision whether to continue or to stop the work (and release the product) should be straight forward.

What do you think?

I would be interested to hear about techniques that people use for backlog prioritization, whatever formulas exist based on ROI, risk, customer feedback. So when we come to a release planning stage and get a chunk of
requests from our backlog they are already pretty well prioritized.
We just add final rifinements, check estimates and see how many
of those features we can do given our time-frame
(or should we re-consider the deadline?).

Thanks,
Alexey