The original idea of stories was pretty simple—write something on a card, talk about it, and agree on what to build. Then, complete the cycle by building it and learning from what you’ve built. That’s it—pretty straightforward, right? If you’ve been involved in software development for even a small amount of time, you know nothing is that simple. Stories go through a long journey with lots of conversations involving lots of people to move an idea for a product, feature, or enhancement into your product, and then move that product out to market. The good news is you can use stories and storytelling all the way through. And I promise that relying on stories and storytelling will help you all the way through.
I ended the last chapter by talking about Sydnie’s cake and the idea of breaking big cakes into little cakes. But software is a lot less tangible, and size can’t be measured in inches, centimeters, ounces, or grams like it can with a cake.
The original idea was that a user or a person who needs something could write what he needed on a card and then we could have a conversation about that. The person who needed it didn’t figure out how to express his need as something that would take only a short time to develop. It was need sized.
A right-sized story from a user’s perspective is one that fulfills a need.
When it comes time to write software, there’s big benefit in writing, testing, and integrating software in small parts. If I can see ...