I recently came across a fresh way to help people work towards the higher level goals of a project. And while I’m not 100% sure of it, I wanted share it because it has some valuable insight.

I was speaking to a group about making agile development work in practice in a corporate environment, and as part of this I had said that committing to estimated stories was very important for successful adoption of agile development. That’s mainly because the people who are paying you deserve to know what they’re getting for their money. It’s also part of building trust: by committing to stories you’re also demonstrating commitment to the business — you’re putting your reputation the line, it gives people confidence to know you’ve got skin in the game.

But talking afterwards to an experienced developer and coach I changed my mind about the details. He said he found it was often useful to commit to delivering stories-as-outcomes rather than stories-as-features.

I had always seen developers estimating user stories as collections of features, but estimating stories as outcomes might be more productive. It should be equally valid, if you can have a meaningful conversation with your stakeholders about outcomes (rather than “I want this because I said so”). It also helps everyone raise their eyes as to what the work is about: software has to be for a purpose.

Of course, software is still, at some level, a collection of features. If I have some doubts about this approach it’s that attention to detail in features can make or break a product, so those low level things can’t be overlooked. I’d be interested in others’ views on conflict. But at the very least the idea to commit to outcomes rather than features does demonstrate that there are plenty of ways to help people work together towards the bigger picture.