Rethinking story commitments

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.

2 thoughts on “Rethinking story commitments

  1. As someone coming from the UX angle, committing to outcomes sounds like an interesting idea. If anything I’d feel it might make focusing on the details more important, as to deliver the outcome, you need to nail the details. I’ve found that sometimes a feature can tick all the acceptance criteria and still not really deliver the desired outcome.
    This seems especially true when eliciting behaviour. i.e. simply being able to do something isn’t enough to get users doing it.

  2. Hi Spencer. I like the idea of it making the details more important. If the outcome is well defined (and it really should be) then it should definitely bring clarity there.

Comments are closed.