Archive for March, 2020
Whenever we teach/learn how to write user stories, we usually use the “As a… I want to… So that…” format, like so:
As a <persona>I want to <have a capability>So that <value this story brings>
It’s not uncommon we end up writing stories such as this one:
As the system
I want to remove duplicate entries from my address database tables
So that I don’t have duplicates
I hope that story has made you cringe. If it didn’t, what’s wrong with you?
Thinking about the Purpose of a User Story, let’s ask:
- How does the story above help the business either make or save money?
- Is “the system” a valid persona? (…maybe one day it will be, I guess…)
- Why is it important that addresses are stored in database tables (as opposed to documents or CSV files)?
- What’s the problem with having duplicate addresses?
- How does that story bring value to the business?
What if we rewrite the user story in this manner:
As the marketing manager
I want to send direct mail with no duplicate addresses
So that I save on mailing costs of marketing initiatives
- The story brings value to the business by saving on mailing costs;
- It makes it clear that the value is important to marketing managers;
- It indicates that sending direct mail for marketing initiatives is the business operation affected by the story;
- No technical details are specified;
- Any non-technical person can understand it.
With all that being said, here’s a question: what’s the single most important part or sentence in that story?
Here’s the answer: the “so that…” part. It is the part that tells us the purpose of the story. The why. It tells us how the story brings value to the business. It tells us why somebody is willing to pay money to see that story implemented.
Last But Not Least?
So, why is “so that…” the last part of the story?
Why build the suspense?
We shouldn’t expect anyone wanting to create cinematic versions of user stories, so let’s cut right to the chase and highlight the most important part of the story, by rearranging it like so:
In order to save on mailing costs of marketing initiatives
As the marketing manager
I want to send direct mail with no duplicate addresses
Right there, Start with Why. But first, let’s give credit where credit is due: I’ve first learned about changing user stories to go from “so that…” to “in order to…” on the Cucumber website. It made a lot of sense to me (it still does!) several years ago and I stuck with it.
That approach is so ingrained into my way of thinking that when I see a story written as “As a, I want to, So that”, I end up reading it backward (by reading the “so that” part first).
Why does it matter?
Over the years, I’ve sat in many meetings (Sprint Planning, backlog refinement/grooming, etc.), where the leader reads the story out loud following a pace that looks somewhat like this:
- “As a…”, spoken kind of fast, but the words can still be clearly heard;
- “I want to…”, spoken slowly, emphasizing the “want”
- “So that”, spoken fast, words hard to distinguish. More of a slur, really. That’s it: the person is slurring, not speaking.
But wait: if the “so that” is the most important part of the story, why are we slurring through it like that?!
There’s a lot of focus going into the want part, but not as much going into the why it’s wanted. In fact, I’ve seen a lot of time spent discussing “want this” and “want that”, and from little to almost no time spent on the why.
First Things First
My recommendation to people has been to start every user story with “In order to…”. If we don’t know how to finish that sentence than we don’t know what the value of the story is, and therefore, no time should be spent on anything else. Who the persona is (“as a…”) and what is wanted (“I want to…”) become irrelevant if the story lacks a strong why (“In order to…”).
In the example story above, after finishing the “In order to save on mailing costs of marketing initiatives” sentence, someone might raise a hand and say something like “I’m aware of a special service deal where we get significantly reduced shipping costs over X number of letters”.
At that point, the focus of the conversation could turn to figure out if there’s any chance that the cost to build and operate the new future would be more money-saving than the available service deal. Yes, software is NOT always the best solution, can you believe it?
Consider Adding Context to the Persona
I’d also recommend considering adding a context along with the persona in a user story, as described in this blog post. Take this contrived example:
In order to end my hunger
As a person
I want to get some food
Is the person really hungry for food? Maybe the person is just thirsty (the feeling of thirst and hunger can be very similar), so while the person may “want” some food, maybe what she “needs” is water. Adding some context to the persona would help clarify things:
In order to end my hunger and not get a stomachache
As a person who hasn’t eaten for 18 hours
I want to get some light food
Often, after adding context to the persona, we may end up seeing bits of information that should be added to the story in order to further clarify things, as it happened with the example above (chugging down a heavy meal after a period of 18 hours without eating probably wouldn’t be a good idea).
As a User?
And please, if the “As a…” part of a story reads “As a user”, take a step back and think a little harder about that; user is too generic of a persona!
A User Story should convey the value its implementation brings to the business. Value may directly or indirectly relate to money figures. Happy users lead to value.
It should always be clear if a user story helps the business either make or save money. But what about non-profit organizations? Simply replace “make money” with “make someone happy” and “save money” with “save someone from pain”. That’s value. You got the idea.
User Stories are placeholders for conversations. These conversations must be centered around value (not technology or implementation) and it should be approached from different angles, until both stakeholders and development teams are clear on the value.
Improving is committed to sharing our knowledge and time freely with the technology community of Houston. We provide our stakeholders, be they consultants, clients, or members of the local tech community, opportunities to both learn and teach at locally hosted Classes, Training, User Groups, TechFridays, ‘Lunch and Learns,’ and now our Live Streaming Webinars.
If you have not had the chance to sit in on one of the Lunch and Learns given by an Improver, now is your chance. As we continue to find new ways to give back to the IT community and make it easier to access these insightful talks, we would love for you to attend and give us your feedback.
This event is open to everyone, and I hope you will join me in spreading the word to your community. You can register on EventBrite below with links for the live stream to come.
I hope to Virtually see you there!
I had seen Derek Sivers’ “Now” page a while ago (this is what that’s all about), and I finally decided to create my own Now page. So, now whenever anybody send me an email or text asking me “so, what have you been up to?”, I’ll point them to that page. Check it out: https://lassala.net/now/
I’m not sure yet how often I’ll update the page. At a very minimum, at least when I do my monthly review, at which point I check my current plans, which are derived from my previous year’s Annual Review. That’ll be a good way to make sure I’m still on track, and/or reflect upon course correction throughout the year.
I’m in Dallas to speak at the QA.Improving.us user group tonight, March 9, 6:30-8pm.
This has been my favorite talk in the last two years!
Testing in Agile: From Afterthought to an Integral Part
Testing cannot be an afterthought; it has to be an integral part of software development. Is it something that QA teams do? Or is it part of a developer’s duties? Do business analysts play any role in it? What is test automation? Unit test, Integration test, Test-Driven Development, Behavior-Driven Development… what do those mean?! This session addresses all of those questions, as we talk through the importance of tests, the collaboration among team members, the techniques, and practices around different kinds of automated testing.