Your boss wants a commitment. You want to offer a prediction. Agile, you say, only allows you to estimate and predict – not to commit. ”Horse-hockey!” your boss exclaims, “I want one throat to choke, and it will be yours if you don’t make a commitment and meet it.” There’s a way to keep yourself off the corporate gallows – estimate, predict, and commit – using agile principles.
This is an article about agile product management and release planning.
But sometimes, it happens anyway.
The Cranky PM started a great thread of conversation asking how product managers deal with the job of telling customers (and sales folks) that a feature is not going to be available in the promised release.
When prioritizing requirements for the first release of our software, we’ve stressed the importance of including 100% of the ‘must have’ requirements in the first release of the software. We’ve also used Kano analysis to categorize requirements as ‘must be’, ‘surprise and delight’, and ‘more is better’ requirements. In this post we’ll talk about an approach to allocating these requirements across releases.
These articles are written primarily for business analysts and product managers. Hopefully they are helping you with thinking, doing, and learning. Welcome aboard!
Latest Articles
Comments on all Articles