Here’s a thought-provoking piece by John Peltier about ‘selling’ roadmap items to the business.
John discusses ways to make sure that customers aren’t given unreliable promises about the delivery of features or smaller roadmap items. Among other techniques, he suggests being clear to customers about the difference between dates that are the result of proper work estimation by engineers and ‘draft’ dates that are the result of less reliable estimation methods.
John also touches on what can be one of the most bruising aspects of the product owner role: refusing to be steamrollered into re-prioritising the product backlog simply because items have been promised in error (often by a salesperson).
In fact, managing the expectations of customers, salespeople, marketers, managers and developers is one of the key roles of the Agile product owner.
Business people who are used to waterfall projects are used to the idea of having a plan that gives dates for when all features will be delivered – and they’re also used to the almost inevitable failure of that plan.
So Agile techniques such as only attaching dates to roadmap items that have been estimated properly are likely to invite skepticism initially. It’s through consistent delivery on the few promises that we make that we educate our stakeholders and build their trust.
That, and the wonderful flexibility that Agile allows – “You need to respond to an unexpected business challenge with an urgent new software feature? Sure: let’s talk to our developers to see if we can put back feature X and deliver what you need in a month’s time” – give product owners credibility so that we don’t need to feel that we must make promises that we suspect we can’t live up to.
One useful technique that John doesn’t mention is to attach a ‘Needed By’ date to features – but only when they are genuinely needed by a specific date. That way, each time the product backlog is worked on, the product owner can decide whether each of those time-sensitive features need to be re-prioritised. In some cases, this will mean de-prioritising a time-sensitive feature or implementing a workaround because it’s clear that higher-priority items will mean that the feature cannot be delivered when it is needed.
Such small-scale feature-level ‘failures’ are actually a strength of the Agile methodology. It’s because Agile projects are able to fail at the small level, with full visibility of the failure to all stakeholders, that they are resistant to failure at the large scale.