Keep Your Product Owner in the Loop with Intermediate Deliverables

It’s ideal to write stories that can deliver a feature, end-to-end, all at once. But sometimes–especially when integrating with new systems, dealing with complex data processing, or working with a complex story dependency graph—it makes more sense to break up the work so you can deliver each story as its own link in a long chain.

But while you and the rest of the development team may be able to clearly understand each link in the chain and visualize it independently, your product owner may not. The more links you have in that chain, the more expensive it will be to change the final product when it’s all in place and you find out it isn’t quite what the client needs.

How can you give your product owner more of a chance to see the value you’ve delivered and evaluate it usefully against their requirements? Try intermediate deliverables.

For example, picture a web service that consumes some complex data from another source and transforms it into a structure resembling what you’ll present it to the user. Your product owner can wait until the next story comes along to wire up a complex UI to that web service, but you risk putting a lot of work in and still missing the mark on their expectations.

Instead, channel your inner dirty hacker by coding up a quick script that can talk to the web service and output plain text. This kind of demonstration can give your product owner a visual idea of what the transformed data will look like in the final product. Plan to throw this script away when you deliver the real thing, but consider saving parts of it (e.g. negotiating service authorization) for future intermediate deliverables.

Ask your product owner for some varied and real-world examples of the things they want to see. Then run your demo script to provide a rough idea of what those things will look like. Resist the urge to make it over-configurable, but consider the value in allowing your product owner to run it themselves and supply their own inputs. Let them play while you focus on the final product, and keep your ear open for any issues they might identify.

Not only will this help you identify issues early (be they from unspoken requirements or simply unknown complexity), but it’ll help keep your product owner fully engaged and feeling like a part of the team. In some cases, they may even uncover reliability issues that otherwise might be easy to miss. And you, developer, will find yourself with an even deeper understanding of the domain and technical aspects of what you’re building.

The little extra work you’ll put in is a small price to pay for all those advantages, isn’t it?