At its core, Agile is about delivering value, getting feedback, and repeating the process as quickly as possible. In most Agile organizations, value is described in user stories. Over my years leading software and product development teams, I have seen many different permutations of user stories, and different styles work for different teams. Regardless of which user story permutation you use, one question remains:
What is the real motivation for a user story?
At it's very basic level, a user story is a conversation starter. The first goal is to get the development team and the Product Owner (or customer) speaking about the desired outcome. If there is a lack of communication at this phase, the delivered outcome can be wildly different than what was expected. By having a conversation and sharing a vision with the team, they can begin to understand the needs and wants of the customer. And it's important for the whole team to be a part of this conversation, as each one can bring a valuable perspective which may stimulate additional discussion.
Agile Coach: Ok let's discuss what's at the top of the backlog.
PO: The most important thing to me is this new transaction search. The users of our app really have no way of discovering details or investigating their transactions. Based on some user group polling, we know it's important to them. I think we can really increase the joy and satisfaction users have if we can deliver this.
Dev 3: Sounds interesting. Dev 1: How do users currently find information about their transactions? PO: Right now they must scroll through their transaction list with no way of telling what the details of the transaction are without opening the details of it. It's a really poor experience.
Dev 2: Yea, that does sound frustrating. What are your thoughts on making it better?
The team wants to deliver the right value; this conversation helps reduce or eliminate the delta between what was requested and what is delivered.
The second goal of the user story is to understand the effort involved. Here the conversation centers on the development team asking as many questions as necessary to size the user story relative to other user stories they have completed. This relative sizing is important to help the Product Owner prioritize and answer "When will x be done?"
Sizing is just one part of the prioritization equation, business value being the other. The two combined allows the Product Owner get the most bang for their buck as quickly as possible. Because sizing is based on effort and not time, "how long" cannot be answered.
Different teams have differing points of view on what they desire. I've been on teams which have used the common story point, and others which have used t-shirt sizes.
Dev 1: That sounds like an XL to me. Dev 3: Well if we compare it to the last XL we did, I think it's more effort, so I would say an XXL.
PO: Ok, that sounds pretty large. I'll go back and see what I can do about breaking it down.
Remember, each team will have its own scale so the values of that scale do not matter, and you cannot compare one team's values to another team's. For example:
Dev 2: That sounds like a banana to me. Dev 4: Well if we compare it to the last banana we did, I think it's more effort, so I would say a cantaloupe.
PO: Ok, that sounds large. I'll go back and see what I can do about breaking it down.
Or
Dev 2: That sounds like a squirrel to me. Dev 4: Well if we compare it to the last squirrel we did, I think it's more effort, so I would say a raccoon.
PO: Ok, that sounds large. I'll go back and see what I can do about breaking it down.
What matters is the relative sizing between the user stories. Is story B less effort than, about the same effort, or more effort than story A.
Beyond acting as a starting point for discussion and questioning, there is no single prescription as to what a user story should be or contain. Let me share my experience on what I've found to be most valuable when it comes to creating user stories.
1. Value statement (As a <role> I want to <functionality> so that <value>)
2. List of functional requirements
3. List of acceptability requirements
4. Simple spec
5. Wireframes/mockups
You may be saying "WOAH! That's a lot of stuff for a user story!" but if the scope of the user story is appropriately small, this ends up being quite small as well. Let's break this down a little with an example of creating a simple transaction search:
What you see above is what I expect the PO to come up with. Or, in some cases, the PO and the Development Team after discussing the story together. In some cases, the above could be considered sufficient. "Ok looks like we all understand the value here and it seems reasonably small."
In others, perhaps not. "I think this is bigger than it seems. I have some concerns…"
Let's explore how this user story could evolve in a story discussion between the PO and dev team. Again, the goal of this is to reduce uncertainty, eliminate scope creep, and help drive predictability by making each user story small and understood.
Dev 1: What should the auto-complete show?
PO: Anything that matches what the user types.
Dev 2: What do you mean anything? What fields? Merchant? Amount?
PO: Hmmm. Yes, Merchant Name, amount, account number, and date.
Dev 1: Ok, should these all be listed together? Do all these fields need to be displayed during the auto-complete?
PO: Yes, for each item searched, all the fields searched should be shown in the auto-complete list.
Dev 2: Ok, so there needs to be a drop-down list which shows all the fields of an item which could be potentially matched upon. Do we highlight the field(s) which do get matched?
PO: Yes, we'll want that.
Dev 1: I think that this is going to be too big. We'll need to split out some of the search functionality into separate user stories.
Dev 3: I agree.
Dev 2: Agreed.
Why would the developers want to split this out? What is considered too big? Is it possible for something to be too small?
General guidance is a story should consume no more than 1/4 of the duration of one sprint. That said, regardless of sprint duration, I tell my teams the target maximum size should be about two days in length, with no minimum size. In this case, by asking a few clarifying questions, the dev team discovered there were some implicitly expected bits of functionality which were not described in the original user story.
Something very important to remember with all of this though is size != duration. Just as you can tell me a grape is smaller than a strawberry (most of the time), a dev team can say whether a user story is more or less effort than a user story already completed; most of the time.
By splitting the user story into smaller user stories, the team gains better clarity on what is requested and the product owner gains more options for prioritization.
Now, let's see how the discussion evolved that story.
PO: Ok, so we could do Transaction Search and still deliver value without the autocomplete portion.
Dev 2: Right, but I still have some more questions.
Dev 3: Me too. Dev 2: When you say accessible from anywhere, what do you mean? PO: The search should be available from the top menu, or hamburger when displaying on mobile.
Dev 1: Ok that's no problem.
Dev 3: I want to talk about the autocomplete. I think there are two parts here. One is just showing the transaction name on any match, the other is the appropriate display of all the fields in a dropdown. There really is not much room there to show four fields all the time and highlight them. I think something a little more intelligent which shows just the field and maybe some subset of the other information would be better. Dev 2: Yea, that is going to take some work to do though. Dev 3: Agreed. PO: You know, that makes sense. How about we split that story into showing just the merchant name, and then another one which deals with showing more enhanced information.
As different members of the team thought about different portions of the desired outcome, they discovered additional scope which was not described within the original user story, and that scope was non-trivial. Each member of the team has a different perspective and without those perspectives the team's chances of delivering the wrong thing increases. If the team had not brought up the "Enhanced autocomplete" functionality and identified it as a separate user story, the Product Owner may have been surprised the functionality was not completed by the end of the sprint.
If you compare these to my original list above, you'll see we've covered the value statement, list of functional requirements, and list of acceptability requirements. We're still missing two items thought — the simple spec and the wireframes.
Let's see how the team goes about those things.
Dev 1: Ok, we all agree these are reasonably sized stories. Let's talk about what needs to be accomplished.
PO: I've got the wireframes here and I'll attach them to the stories.
Dev 2: For the transaction search spec, how about "Search box available in the top bar menu. Search will call API and return results in json". Dev 1: I think we should add "Search occurs upon submission". Dev 3: Works for me. Dev 1: For the autocomplete functionality lets go with "API Call will be made on every change to search box. List will be displayed five deep, or until bottom of viewport. No scrolling. Arrow keys can select a suggestion" Dev 3: I think the arrow keys selecting something should be a separate story. It may seem simple, but I think there are some nuances to it. Dev 2: I agree.
PO: Is it really that much more work?
Dev:3: Yes, I think it would make the user story bigger than any of the others.
PO: Alright.
Notice how the Product Owner was surprised that something was more work. Remember, the dev team are fully empowered to accept or deny any user story into their iteration. It's up to them to determine if a user story is too big or not, no one else. The Product Owner is then empowered to determine the value that user story will deliver, enabling him to pick and choose what has the highest priority.
You can see how something small which may have been taken for granted is split out into a new user story.
Over this whole exercise, the team went from having what could be considered a vague idea of requested value, to a more specific understanding of requested value. Through the conversation, the team was able to break down a user story — which did not fully define the goals of how the user should be able to interact with the product — into four user stories detailing exactly how the user will interact with the product.
You may have noticed that a couple user stories don't have specs. Specs are not always necessary, although they can be very useful. I've found the simple style specs above are helpful to remind the eventual team member who works on the user story to remember what was discussed. If something is trivial enough, or well understood, teams may choose to skip this.
This is where we differentiate our specs from full technical specs which historically detail a full implementation guide. A simple spec is NOT architecture. Architecture should occur during the execution of the story in the sprint by the folks working on it. The spec can help guide those decisions by helping to define the discussed implementation.
I mentioned wireframes but did not show any. These do not have to be complex, but I do believe they are very important for any user interface. Something as simple as a quick sketch on piece of paper, or as others have described it, the back of a napkin, is more than sufficient to guide the team on how to implement things. Ideally the final UX design work will occur as part of the implementation of the user story.
In Agile development, it's important to keep the scope small and simple. If user stories are too large, it becomes very difficult to size or set expectations. User stories get the conversation started between product owners and developers, providing the opportunity to leverage strong, collaborative teamwork to focus and perfect that scope. Different teams will have different takes on what user stories contain, but the focus remains the same — starting a conversation so you can deliver value as quickly as possible, measure and adapt, rinse and repeat.
DISCLOSURE STATEMENT: These opinions are those of the author. Unless noted otherwise in this post, Capital One is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This article is © 2017 Capital One.
For more on APIs, open source, community events, and developer culture at Capital One, visit DevExchange, our one-stop developer portal. developer.capitalone.com/