Blog: January 30, 2013
What size is the right size for a user story?
We’ve recently hired another business analyst, and I’m excited to work with her to explain how we do user stories here. I worked with this analyst at a previous employer, and the way we approached user stories there was significantly different than at Red Arrow. Perhaps the biggest or most obvious difference in user stories is just the sheer size. At the previous company, we often built upon the same “user story” (I use that term loosely - it was really more of a feature or feature area spec in some cases) throughout the project. So, by the end of the project, some user stories were just massive, and typically were confusing and convoluted at some point. At Red Arrow, our stories are sized in a way that is probably more appropriate for a user story. Though I’ve learned that there is not a global, hard rule for what exactly “right size” means. Many business analysts are familiar with the INVEST mnemonic for well-written user stories.
I won’t go into more detail about all aspects of that mnemonic at this point (a web search on “INVEST user stories” will get you some good information), but I bring it up because it’s a model I use as I’m writing user stories.
Independent and valuable vs. small
One of my main struggles in finding the right size is striking the balance between “independent” and “valuable” versus “small.” I can probably explain it best with an example. Let’s say I have an application that requires some level of security, so I have a user story for registering my account before I can log in. At first we might have one high-level “User registration” story. But, after discussing it with the team, we see some distinct components of that process: 1. User chooses to register and fills in demographic information 2. System needs to confirm their email address is real 3. User needs to specify their password and complete their registration I could stick with that single high level “User registration” story that encompasses all three of these aspects of the registration. That story would certainly be independent, and valuable. But is it small? I could also break the story up into three parts: Enter demographic info, validate email, set password. These are definitely smaller, but are they valuable on their own? And, without being able to enter my demographic info, I really couldn’t validate the email, could I? So are they really independent?
Independent, if done in order
One conclusion I’ve come to is that it’s okay to have user stories that assume an order of implementation in some cases. I’m not sure an agile “purist” would agree with that assessment, but it’s worked for me, and I think the benefits can outweigh the negatives. Back to the above example. I’d probably go the route of creating three separate stories. Within the stories that have certain dependencies, I’d include a note explaining the dependency or relationship with another story. So, the “Validate email” story would include a note that says, “Assumes user has entered and submitted demographic info, including email address (covered in “Register with demographic info user story”).
What’s the benefit?
The biggest benefits of this approach are that the stories are smaller, so the team can get it done faster, and then the feature can get into QA’s hands faster, which can bring up bugs or questions faster, etc., etc. It’s true that being able to enter and save my demographic info might not be terribly valuable to an end user completely on its own. But there is value in getting part of the whole feature working and tested. And, especially if you’re doing some sort of greenfield development where you won’t have a production-shippable product right away, it’s okay then if one of these stories is completed in sprint 1 and the others are in sprint 2, for example.
Right-size based on project or team
Another conclusion I’ve come to is that what’s right-size for one project or team may not be for another. For example, I’ve been working on a project to port a very robust, complex application to a new technology. The team was overwhelmed by how we’d address all of the complex business logic built into some of the features. In that project, we’ve taken an extremely granular approach to user stories. We have stories for just being able to enter record basic data for an item, with no business logic. Then we have separate stories for each layer of business logic so we can build on top of the basics. So, for example, for a feature I might have separate stories for:
- Add item X to the system
- Validate required data for item X
- Automatically fill in field Y based on selection of field X
- Disable field B based on value in field A
- And so on…
This allows us to make real progress on a feature without getting bogged down immediately in all of the details. Plus, with a tight timeframe, it gives the product owner a chance to be very particular about what rules we really need to replicate in the first release, vs. which can be prioritized for later. In a less complex application, I probably wouldn’t typically have user stories quite that granular. In those cases, I would likely have one main user story for “Add item X,” and then break out the other business rules into acceptance criteria scenarios within that story.
It’s called “agile” for a reason
Though it’s probably a bit unstable to constantly alter your approach for a process, don’t be afraid to change your approach when it comes to user story size based on your specific situation. Remember that your main goal as an analyst isn’t to write a user story in a certain way. It’s to create user stories that convey the business needs to the development team, with the ultimate goal of building the right software.