In this blog post we will talk about how you can reset your understanding of user stories, so that you can make them useful again in your agile toolkit.
There’s too much noise, formality and wrong stuff being done with user stories. If your approach to product development, and in particular software, is not streamlined when you utilize user stories, then you are doing them wrong.
Luckily, it’s not unfixable.
So let’s start making user stories useful again.
The origin: solving problems through shared understanding
User stories had a great beginning in the late 1990’s, at the heart of XP , a great model for agile software development.
The creator, Kent back, said they were an “antidote to requirements”. Why? Because we used to have a long, long phase of analysis and design, usually creating use-cases and non-functional requirements. Those were documents. Looong documents.
Remember that when agile started, we wanted to make it about people interacting and collaborating, not documents being handled. We also wanted to make sure we had the customer in mind, because without that we can focus too much on the technology aspects or just have a complete misunderstanding of what the functionality is about. And end up not delivering what we want in agile, which is VALUABLE software.
Writing requirements as a business analyst seated somewhere in the org, then having a design document made by an architect also distant, then some software written by other people… you get to see there was too much of a separation of the understanding of the problem
Not to mention that usually requirements and the whole analysis phase would think about some business and (maybe) user perspective, but not the customer. What do I mean by that?
Say you are writing software for a bank: they are your customers. The users of the bank’s system might open checking accounts with them, and you want to understand these users. But very importantly: your customer being someone representing the bank has regulatory items, ideas, and dates in mind that the users (the ones who asks for a cheque) might not have a clue.
In its very origin, the customer would write the user stories.
That would then involve both customer and domain knowledge AND how the users interact with the systems.
I hope that helps you situate the humble beginnings of user stories as an agile tool.
The evolution: towards the 3 c’s
Another great XP practitioner, Ron Jeffries, when seeing confusing and misuse back then proposed early on that we started using cards. Yes, cards like these.
And then the logic that we’d use to fill up and use these cards would be the 3 C’s: Card, Conversation and Confirmation in this order.
1 – The Card
As you saw, the card is small. And that it’s so you don’t get carried away and write a big requirement. Whatever the user needs, has to fit the card. It must be about the essentials. You can already see what a difference from big requirements documents, such as long use cases with several pages.
What we are interested in adding here is what is the work to be done, why are we doing it, and to whom it matters.
Here’s an example of a what you could written in a card :
“Job seekers (users) can view the information of each job in a saved search.”
2 – The Conversation
Then for everything else… let’s talk. It’s in the conversation that flexibility resides. That scope elasticity that I constantly mention.
Don’t get confused. The card is important, but this is the main piece: the conversation, the discussion. User stories cards are token for discussions. Nothing else. Don’t get attached to the specific document.
As we read it though, we start discussing with the rest of the team and with the customer:
- Any kind of job seeker or just the paying ones?
- Do they see a preview in the search before they can look into each job entry?
- What information will they be able to view?
And so on. It’s through the conversation that business and technical challenges appear. And that we start understanding how much work is actually required. And when to stop. Which comes next.
3 – The Confirmation
As you have that great conversation, it becomes clear that now you must negotiate. Otherwise, that simple statement can become a full system on its own!
So you state what completion looks like. What is enough; when you know the job is done. And that is what you can use to test to accept. So your completion criteria should be stated:
- All types of job seekers can view the information. You will test for paying, free and admin users.
- The information they can see is <…>
What about “The template” of user stories?
Shortly after, folks at a company called Connextra experimented with the famous format:
As a <user>
I want <something>
So that <reason>
And you might wonder why this template. In here we could have:
“As a job seeker I want view the information of each job in a saved search so that I can avoid applying for the same job twice.”
Not because the job seeker just wants to look at it, but to avoid applying twice. And with that in mind, we might start seeing a second possible user story: the one about the user being prevented from applying to a job they already applied. Or maybe not. Maybe we’ll leave that to the job seeker discretion because in the timeline we have to deliver the system that’s not that important.
Remember the 3 Cs!
Another reason for the template is: just think that as you wanted people to tell their stories, you would also want them to have it be concise. So people would not have to struggle with form.
Now, that format was a guidance, a suggestion. It’s meant to be useful, not a straitjacket as we see today. Don’t follow it religiously. In fact, you don’t need to use it at all. The point was to highlight the WHO/WHAT/WHY aspects, so we would understand how valuable the work truly is. And therefore, be able to negotiate and prioritize.
Which was the intention all along, opposed to one big, confusing requirement document.
What about technical work?
User stories are about the users.
When you need to work on a specific stabilization of the database or improve your build system so that you can deploy faster, that does not warrant a user story. You user doesn’t care about those things.
So they are NOT user stories.
You can only write things such as:
“As a tester I want…”
If your system is aimed at testers. Testers as your real users. Not colleagues in the team.
But hey, that work on the database still needs to be done. What do you do then?
No need to despair. That work will be represented somewhere where the development team needs to see it and keep track for their own management. But:
1 – you don’t need to show it to the customer in demos.
2 – use the idea of user stories, not the format, to think about the work just the same. Not only because even technical work needs to be properly prioritized, but also because it’s possible some of that work might be expressed in the template and directly impact what the customer needs now, anyway.
Discussing the why of apparent “just technical” work is still important. What will win the priority battle and be worked on first? The database maintenance or the new step in the build system? You need to know what you will gain, how much time you expect to spend on it to be able to decide what to do.
Think of user stories as a tool to format your thinking about the problem, and how to offer small, valuable pieces to complete the solution, instead of attacking things big bang.
Final words
User stories are an agile tool for bringing businesspeople, technical people and customer closer together. That’s the spirit of agile. In the same spirit, it’s also a way of having people collaborating and interacting, instead of focusing on writing requirements specifications.
In fact, once the story is completed, feel free to rip it!
Really, the documentation that should remain is the code, including the tests done, the design graphs, and the eventual minimal documentation that makes sense to exist. NOT the user story itself.
The user story being a tool, a vehicle.
Since this is a topic I’ve been receiving a lot of questions about, stay tuned for upcoming posts detailing how to write user stories (without the template), how to split them, how to hold that conversation and how to plan using user stories.
