You’re a product owner, and you have an idea. In your mind, it’s pure, simple, and beautiful. You want to hold onto that idea, to nurture it, cherish it. Reality, however, has other plans. You’ve got investors. You’ve got a team of hungry developers and designers licking their lips. You have to feed them your idea. So you say it. And immediately the illusion is shattered. The designers and the developers start asking questions. They force you to come up with concrete examples. You start breaking the idea down into features. One developer comes up with an edge case you hadn’t considered, forcing you to rethink your idea entirely. BAP!
You’re a designer. You’ve worked hard for the past several months to create a holistic design and a sane, coherent user experience in what has turned out to be a very challenging problem domain. And then your product owner walks in one morning and explains that the product is going in a new direction. Your entire user experience is shattered. You find yourself picking apart the workflows, trying desperately to put them back together in a way that still makes sense. KAPOW!
You’re a developer. You are proud of the application you’ve built. Your classes are well-factored. Your domain is well-modeled. Your class names make sense to even the newest person on the team. Your patterns are so well established that you can build on an existing feature by simply throwing in a new subclass. Your test suite is fast. You’re ready for anything. Except what your product owner just said. You didn’t see this coming. Your code is woefully unprepared to accommodate this new feature. You’ll have to rethink at least a dozen objects in order to implement it. ZLONK!
Building software is hard and painful, but this is what we know:
-
Good stories make good code.
-
Writing stories are a collaborative process between the product owner, the developers, and the designer.
-
A story can’t implement half a feature; if you can’t put it in front of a user and get meaningful feedback, it’s not a story.
-
Stories start with business value. If you can’t identify what value your business will get out of the story, your business has no business with it.
-
Stories consist of concrete examples. You can’t wave your hands at computers, so don’t hand-wave your story.
-
Talking through edge cases as a team helps the team understand what the product owner actually values.
-
Roll with the punches. The story of your application will change. Build a team that embraces that change.
