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 […]
Flashback
Posted on:
Flashback: A Year Ago This Week on Tyner Blain [2006-08-18]
A look back at the best from a year ago.
Communication / Consulting / Product Management / Project Management
Posted on:
Failure To Deliver Is Not An Option
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.
Agile / Project Management / Software development
Posted on:
Agile Release Planning With Games
Leading Answers, an agile project management blog, has a great article that details some agile techniques for release planning exercises. Their article includes explanations and great diagrams.
Slightly off-topic
Posted on:
Version Numbering Makes Release Planning Harder
David, at 37signals, writes an interesting post about changing the way their company is managing the naming of new versions of their Backpack information manager product.
David starts with the premise that there is too much feature-creep when scheduling deliveries of software updates.
Process Improvement / Requirements / Software development
Posted on:
Prioritizing software requirements across releases
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.