Constructing Effective User Stories, or, My User Stories Bring All the Boys to the Yard
User stories are…
And this is where I get stuck. I’ve been so enveloped in writing user stories for the past year that I seem to have forgotten the basics. I’ve forgotten how I got to where I am now. When I started my position as a business analyst, my knowledge with software was…limited, to put it nicely. I didn’t have a damned clue about what I was doing. And The Google couldn’t help me either. Sure, I found some things, but everything I found made me look up something else. Everything was written a tier or two above where I needed it to be. I needed a really good starting point to kick me off but everything just skipped over that valley of basic knowledge and into the stuff that people really want to read.
So let me try to start from the beginning.
User stories are meant to capture the essence of the business value of a system, and are written in everyday language. For example:
As an oceanographer I need to cut open this shark so that I can see if that little Kintner boy is inside.
Ok, this is not a software requirement per se, but I am watching Jaws and it is shark week (love!), so deal with it. Here is a real user story:
As a nurse I need to be able to set my default location so that I am viewing my preferred data when I log in to the Nursing Station app.
Here is the breakdown of that story, and the basic format for user stories:
As a [role] I need [feature] so that [business value].
The nurse is the user who will be using the Nursing Station app. She needs the ability to set her default location so that she won’t have to waste time setting or selecting a location upon each login to the app. The business value implied here is that she won’t be wasting time doing this and can instead get some actual work done fast and not hate on my software for being unusable.
Depending on how long you’ve been writing user stories, you may or may not have learned a very true, key fact: users get in the way. They don’t know what they want but they will be damned sure to tell you. You will hate it. Do not count them out. Regardless of the way they present themselves, you need to come at it with the mindset to figure out the actual need there. If they are nagging you for a button or a field to enter a number, determine why they need it. If they just want it because of the way it looks or for an insignificant value/one that may a) mess with the rest of the software or b) tack a lot of development time on, probably don’t just give into their needs (in the long term they will start yelling about how long it’s taking, and when you throw that “you needed this button” back in their faces they are none too happy). Figure out why they want what they want, what purpose it serves, and if it works for all of the people who will be using the software. We don’t write code for edge cases, we make it work with edge cases.
The INVEST model
The INVEST model is the shit. It is one of the best things I have discovered for improving my user stories. This blog (http://www.agile-software-development.com/2008/04/writing-good-user-stories.html) has a really great summary of the INVEST model, which I will expound upon here:
Independent: User stories should be as independent as possible (don’t put something about a link in one story and then separate the link functionality; you’d have a dead link if the sprint wrapped and the complementary story did not get completed)
This is something I have really improved upon in my last year as BusinessCat.
1. Making stories more atomic means less of a chance for things to get tangled up and confused
2. That dead link thing? Yeah that happens. Be careful and make sure all of your stories and acceptance criteria are complete. See my thoughts on MMFs at the end of this beast.
Negotiable: User stories are not a contract; they are reminders for the team to discuss and collaborate to clarify the details near time of development
What a user story really is is a placeholder for a conversation. We’ve gotten away from writing strict, rigid use cases and into these user stories, which are much better for the way the business world really works. By writing a user story this way, I am opening up a higher bandwidth conversation. Instead of a developer just reading what I have and doing it word for word, now we can talk about things and make sure everyone is on the same page and fully understands the business value and the needs of the user. I like that Kelly specified “near time of development” though; that’s one thing you’ll always find: CHANGE IS A CONSTANT. Friggin annoying, but it is inevitable. The closer to development time you talk about something the more likely it is that you’ll have the best information and the most clarity on the item.
“A fundamental lean principle is to delay decisions until the last possible moment so you can make the most informed decision possible.” – Mary Poppendieck, Lean Software Development: An Agile Toolkit
Valuable: User stories should be valuable to the user and written in user language
User stories are user stories. So put on a user hat and write it. You should never have anything like this in a story:
“title attribute displaying formatted address when user mouses over”
I got stuck putting this in a story the other day by a higher-up and I was really mad at myself for letting it in there. Yes, it will tell the developer what to do, but no user would write that. Leave implementation details to the developer. Describe the desired result, not the implementation. What it should say is:
“display tooltip when hovering over address”
There is still a little bit of implementation language in this, but it’s an abstraction higher than spelling out the html. Sometimes you can only refactor so far; I would be happy to leave this in one of our stories.
When I have the conversation with my developers we can talk about this to make sure they understand it, but it’s terrible to have the former in a user story. If I don’t understand it, I shouldn’t be writing it. And I am the user.
Estimable: User stories need to be possible to estimate; they need to provide enough information to estimate, without being too detailed
This goes back to stories being atomic. When we write stories on my team, we make them no larger than 3 days worth of work. If the developers do not agree that it will take three days or less, it’s time to refactor. This isn’t ideal for every team, but we have worked to become a sophisticated enough team that we can work like this. Plus, it’s ideal. If you have massive stories there is more chance for stuff to get lost or overlooked, things will be harder to test, and general craposity will ensue. In summation: Yer doin it wrong.
Small: User stories should be small. Not too small. But not too big.
See above. D’oh. Additionally, don’t be discouraged when you need to refactor your stories a bah-zillion times to get them to be more atomic. You will not get it right at first (I sure as hell didn’t), and a continuous improvement mindset is an absolute necessity to success. Be willing to give it a go, observe the results, and adjust, as an ongoing process.
Testable: Need to be worded in a way that is testable and not too subjective; must provide clear details of how the user story will be tested
When QA tests, they run through many, many different scenarios. If your stories are too rigid they won’t necessarily hit all of the possible scenarios and edge cases. Be sure that you leave the story open enough that people will think about all of the ways the feature will be used.
We recently starting using MMFs (“A minimum marketable feature is the smallest possible set of functionality that, by itself, has value in the marketplace.” – James Shore [http://jamesshore.com/Blog]), which has helped us immensely with keeping things together and not losing track of things. It also makes our releases easy peasy and we don’t miss things (dead links?), etc. If your stories seem to be less cohesive than you would like or you find that things get missed, MMFs might be the right route for you to take and I would recommend using that format (or at the very least checking it out and seeing if it’s for you).
For a little further reading, I would recommend checking out Ron Jeffries’ post on the three C’s: Card, Conversation, Confirmation (http://www.xprogramming.com/xpmag/expCardConversationConfirmation). He’s got some great points that he makes better than I could, so if you’re interested in more detail about writing effective user stories that’s a good next stop.