Customers love user stories.
Project specs? They couldn’t care less. Who wants to read those, much less try to figure out what it all means in the end?
A good user story, on the other hand… those are software specs from their point of view.
A customer could read a user story and say, “Yeah, that sounds about right.” Or, better yet, “Pretty close, but could we change this a little bit…”
That’s because user stories are not written in tech-speak. They don’t focus on technologies and code. They focus on what really matters in a software application: how it gets used.
The results of user stories are more customer-focused applications. More user-friendly applications. More sellable applications. And we all want that, don’t we?
If you’re not already writing your software specs in terms of user stories, I recommend you start right now. Not only will your customers love you for it, but your project teams will love you, too. And you will love the results.
Where Do You Find User Stories?
User stories are found in Agile development processes. They’re meant to provide simpler descriptions of software requirements in plain language that all your stakeholders can understand. Language that business owners, end users – anyone really – can understand.
Traditionally, developers would pick a piece of functionality and say “we need to get this done for our users.” And once they’d planned out all the various parts, they’d break it down into tasks, assign them to the appropriate resources, and only then start writing code.
Naturally, this was a very technology-centered approach.
Agile software development changed all that. Just as the old ways of planning and managing projects were changing, the ways for writing specifications needed to change, too.
User stories were the answer for Agile methodologies. User stories turned the old way of writing specs upside down. Instead of saying to the project team, “This is what you need to do,” a user story tells them, “This is what our users need to do.”
How they accomplish that is left to the project team.
How Users Stories Work
User stories start, of course, with users. And for that, you need to identify a specific sort of user. That’s because different users may have different needs, different prerequisites, and different paths to accomplish their goals. Sometimes you might have a feature where all your users interact with it the same. But you can’t assume it. In fact, you want to try to imagine how different user groups might interact differently with your software application, even if they don’t do so now.
The more thought you put into these user experiences, the better your user stories will be. This will provide better context for your project team to accomplish their goals in ways that make your users happy.
Scrum Alliance uses the following user story template:
As a < type of user >,
I want < to perform some task >
so that I can < achieve some goal/benefit/value >.
Once this basic sentence is established, it’s time to flesh out the details. Why are they using the functionality in question? How are they accessing the functionality? What related tasks are they also performing? Where does the data they need come from?
All of these questions need to be answered to understand the full user experience. Once you’ve figured out what that should be, you’re ready to set the acceptance criteria.
Here at Ascendle we simply use a bullet point list of the conditions that must be met for the user story to be considered complete. Your cross-functional project team will discuss those rules and come up with the best way to actually program it.
User Stories are like Vertical Slices of Cake
Think of a layer cake. When you cut a slice of it, you’re getting a small piece of each layer, plus the icing on the outside.
That’s how Agile development with user stories works.
But in traditional development methods, the development team would plan and build the entire database layer. Then perhaps an entire server logic layer. And so on. Until they frosted the cake with the entire User Interface layer.
A user story, though, only builds what’s needed for that one slice of cake. It still needs to be a complete slice of the cake – including each layer and the frosting on the outside – but you don’t need to take months designing and years developing the whole darn thing.
And it’s more flexible, too. If users decide your slice of cake tastes bad, you can make adjustments to your recipe with each successive slice. You don’t need to throw out the whole cake… or, as would normally happen, try to convince them to eat it anyway.
Why User Stories Are Better
So what’s the real import of all this? Why are user stories so much better?
User stories are better because they capture how the functionality will be used.
User stories are better because they let your development team come up with the best ways to accomplish each task, rather than dictating how they should do it.
User stories are better because people can understand them – including the users themselves. It’s better to get a “no” up front than to get it after – which is what typically happens when users can’t envision what your technical specs really mean.
User stories are better because they lead to more user-centered, user-friendly applications that customers want to use.
And that is why customers love user stories.
