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.
Mindful Software Improvement 
This is a great intro to the art and craft of writing effective user stories. Can’t wait to see more!
[…] Cat Schwamm is a Business Analyst on my team and basically my right hand. She is helping me lead the charge in evolving our development practices and overall culture toward a lean, customer and value-centric organization. Without her, I would have long ago gone insane. Her first post is part one of probably several dealing with effective user stories and software specification, so definitely check it out. […]
Cat,
If you can express user stories with as little mention as as possible of any software, then you’re getting closer to the purpose of user stories, which isn’t to specify software but to communicate a contextualized description of a problem.
So, instead of: 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.
Try: As a nurse I view my preferred data in order to pay attention to {ah ha! something is missing in the analysis! the root cause/motivation!}
There are a handful of weaknesses in Scrum orthodoxy surrounding user stories and contextualized, user-centric design.
Instead of thinking wishy-washy geek distractions like “feature” and “business value”, consider the user’s goal in the work, and the motivation for the goal. This leads to a better analysis of context, which inevitably leads to systems that are a better fit to the task for having more user context communicated through user stories.
My user story format is:
As a [role] I want to [goal] so that [motivation]
I try to drop the “want to” filler and see if I can get right down to an imperative expression of what “I do”, rather than the passivity of something I “want to do” or “need to do”.
The goal is this: As a user, I tell you what I do so that you build software to support what I do.
The goal of user stories isn’t to describe software or features, it’s to communicate the context of people, their goals (the work they are called to do) and their motivations for doing it (context).
Also, the INVEST model is shaky at best. It’s an elaboration on user stories that Scrum added that is only useful in specific contexts.
User stories do indeed have dependencies when they’re used to sequence and schedule work. Which is why I personally don’t use user stories as work items, but as bearers of context to work items.
So, how do you communicate the specifics of logging in and the default location that are essential to your user story above? Flip the card over and write those details as acceptance criteria. Or, if you’re familiar with Context Specification, you can use it.
I’m trying to grok user stories – so this is gold dust.
Thanks for going into practical details that are hard to come by. And great to see additional wisdom the feedback too.
BION I’m imrpsesde! Cool post!
@scott I tend to not like the practice of using stories to sequence work and prefer to sequence work at a higher planning level, leaving the stories purely for describing an instance of context and functionality. Thoughts?
Scott,
I don’t use stories for work management either. Stories flow through the production system only as a side effect of their work items flowing through the system.
Stories aren’t descriptions of work, so they aren’t eligible as work management artifacts.
They inform the people doing the work, giving them (hopefully) an understanding of how they benefit the lives of their users with the software that they’re making.
[…] from the planning post comes in. We start to write stories (Cat has a great post detailing how to build effective stories). The other information gathered to this point sits dormant, with as little specification work done […]
[…] This is where the information from the planning post comes in. We start to write stories (Cat has a great post detailing how to build effective stories). The other information gathered to this point sits […]
[…] For a deeper look at the guidelines we use to construct stories, I recommend you go check out Cat’s post on the subject. Go ahead. I’ll […]
[…] For a deeper look at the guidelines we use to construct stories, I recommend you go check out Cat’s post on the subject. Go ahead. I’ll […]
At last something sensible to say about U.S. that isn’t just regurgitated. Great. I’d like to come to your party please.
I think that organisations come to Agile because they are desperate for improvement. They think the problem is to do with poor software delivery, but I believe the problem is poor requirements (or if you prefer poor ‘user stories’). Which suggests that Scrum/XP solves the wrong problem. There is no real issue with talented developers delivering code. The problem is the business being unable to state what they want clearly. Scrum/XP skirts around the issue of user story management. I think where we go from here is we split into an Agile Requirements practice (ARP) and an Agile Delivery practice (ADP). ADP works well. ARP doesn’t. Jacobson’s view of the essential issues of concern in software engineering echos this approach. i.e. requirements don’t belong in delivery, rather requirements are a formal input to delivery. http://www.ivarjacobson.com/process_improvement_technology/essential_unified_process_software/
I’m a BA working on ideas for making stories better by the time they get to the Sprint planning meeting so planning poker can be done with enough information to have confidence. I do this using a requirements pattern language I’ve been using it since 2003 and it works well. The pattern language works for transactionally-oriented database applications and includes patterns for driving out common personas, minimal persistant representation, data maintenance, lifecycle class, and management information.
The application of the pattern language ensures the upfront requirements work does not take longer than it should. A first cut of the requirements hierarchy tree is always available within a week. The whole set of ‘conversations’ around each candidate user story is almost always done within five weeks – then the sprint planning meeting can start, and it is guaranteed to be short and sweet.
The implementable story hierarchy has project stories at the top. These are akin to ‘Jacobian’ use cases in that they represent the achievement of the user/actor/persona goal. They are the top level of the requirements ‘tree’ and act as the basis of the requirements table of contents. The project stories decompose into release and iteration stories. The entire hierarchy can be traced back to all the business inputs from interviews and workshops. The approach introduces a new definition of ‘epic’ to no longer mean ‘a big story’ (not that helpful) to a more interesting definition that includes:
• Enterprise stories
• Back stories
• Project stories and tests
• Release stories and tests
• Iteration stories and tests
• Constraints
• Implementation tales
• Non-functional requirements
The definition of ‘epic’ shows how all these elements fit together and is supported by graphics and spreadsheets. This approach is really useful early in the project lifecycle. It can be applied during feasibility, and in ‘ideas management’ where management has to decide which projects to fund in the first place.
I’m interested in:
• how to bring the PMO onboard
• how to reconcile the need for ‘governance’ with Agile
• how to give senior management confidence
• what to do when the customer isn’t full time available
• reconciling enterprise stories, project stories, release stories, iteration stories, constraints, acceptance criteria etc. into a big picture
• how upfront requirements/stories can still be Agile (keep it simple, but no simpler than it needs to be)
• a synthesis of Agile modeling and the best lightweight aspects of UML
I’m blogging at masterstoryteller.co.uk. I also write at princelite.co.uk. Visit me!
Peter
You’ve hit the ball out the park! Irncedbiel!
Hi everyone, it’s my first go to see at this web page, and paragraph is in fact fruitful in favor of me, keep up
posting these types of content.
This is really interesting, You are a very skilled blogger.
I’ve joined your rss feed and look forward to seeking more of
your magnificent post. Also, I have shared your site in my social networks!