The idea of stories is simple. Maybe too simple. For lots of people in software development, conversations like these feel very foreign…and a little uncomfortable. And people often revert to talking about requirements like they always used to.
When Kent Beck originally described the idea of stories, he didn’t call them user stories, he just called them stories—because that’s what he hoped you’d be telling. But very soon after the first books on Extreme Programming were published, stories picked up the more descriptive prefix user so that we’d remember to have conversations from the perspective of the people outside the software. Changing the name wasn’t enough, however.
This is my friend Rachel Davies. And she’s holding a story card.
In the late 1990s she worked for a company called Connextra. Conntextra was one of the earliest adopters of Extreme Programming, the Agile process where stories came from. When the Connextra folks started using stories, they found they ran into some common problems. Most of the people who wrote the stories at Connextra were from sales and marketing. They tended to write down the feature they needed. But, when it came time for developers to have conversations, they needed to find that original stakeholder and get a good conversation started—one that included who and why. Just having the name of the ...