Archive for category Software Development
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.
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.
I often hear something along the lines of “I cannot write tests for that UI code!” as the reason for the lack of unit tests. The fact is, more often than not, we can write tests for what seems to be “UI code”. I decided to come up with a talk to explore that topic and will be giving it at the Improving Code’s User Group next month, on March 4th.
In this talk, we’ll explore an approach to either write or refactor UI code so it can be tested more easily. We will NOT cover how to write automated UI tests, though.
Looking forward to it!!
I’m speaking at the North Houston .NET User Group this coming Thursday, Feb 20, 6:30-8:00pm. I hope to see you there!
Code Review: I Mean No Harm!
As part of the work I’ve been doing for many years, I get to do a lot of code review. I usually document things that come up doing a code review so I can share it with other developers in the teams. In this session, I share some of the code I’ve looked at, the reasons why the code raised yellow or red flags in my head, and some possible solutions I’ve proposed.
I’m giving my current favorite talk at the Houston Software QA User Group next Tuesday, Nov 5, at 6pm.
The cool thing about this talk is that it appeals to people in many different roles: developers, QA, business analysts, and product owners. I’ve given this talk at conferences, user groups, and “lunch and learns” at several companies. I’m excited to be delivering it again!
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.
I’ve realized that, over several years, I’ve developed a passion for changing code until it becomes readable. Yes, I’m a Clean Code addict! 🙂
Whatever the programming language, library, framework, etc, I always look for ways to make the code more readable. It didn’t use to be like that; I used to look for obscure language features I could use in my code. What for? Clever code isn’t that great if most other developers can’t understand it quickly to be confident in changing it when needed.
With those thoughts in mind, I’ve decided to create a new user group for those who, like me, enjoy Improving Code.
I hope to see you at one of our meetings!