This is a follow-up to my previous post, User Story Titling. My intent is to walk you through my team’s current philosophy on writing user stories and our process of preparing a product backlog for development.

“Preparing a product backlog for development” can sound a bit final and very misleading. I do not mean that an entire product backlog is fully groomed prior to development. Instead, our product backlogs are usually partially groomed – some user stories are high-level, some are semi-defined, and others are in a state we consider “ready for development.”

Big “A” Agile is about creating working software as quickly as possible – this can mean starting development immediately; however, my team favors a quick start to development, but a slightly slower quick start. Our slower quick start isn’t all-encompassing waterfall, but just an agreement on the state of a user story before we begin development. As a team, we have agreed that in order for a user story to be “ready for development,” several components must exist:

• a well-defined user story, guided by our team’s philosophy of
  • user story titling
  • user story content (this post)
• prioritization
• estimation
• validation by product stakeholders

In this post, I’ll be describing how writing user stories on my team adheres to our philosophy on user story content. This is a multi-part series covering these 5 areas of user story content:

• User Story Text
• Fields
• Notes
• Supporting Documentation
• Acceptance Criteria

User Story Text

In big “A” Agile world, user stories are written in the form, composed of three primary sections “As a [role/individual], I want to [action], so that [business value].” Each of these sections independently is meaningful, but placed together form a triangle of information that both demonstrates our ability to understand what our stakeholders want to do and why they want to do it.

As a…

The first part of our user story “As a [role/individual]” is meant to identify the persons or group of people that will be interacting with our system, while giving developers and backlog groomers a hint on whom to talk to. Remember, agile is about face-to-face communication and individuals and interactions. This first section of the user story immediately puts our focus on the individual. As a developer, this [role/individual] is who we get up and speak to when we have a question regarding the user story. Although it may seem silly at some level, stakeholder involvement is a key to successful projects, and regularly communicating with stakeholders only goes to increase the trust and relationship a project team needs to build and maintain throughout a project. The relationship starts with the user story and will end with the user story, when the project team delivers working software built around the user story.

Practical Usage

As our team begins to develop stories for a project, we often start off with a generic “As a user…”, during our first pass. This helps us focus on the action of what a general user may want to accomplish within our solution. In our second pass, we focus back on the different types of users that may want to perform an action. As we are identifying the different users, this discussion often turns to grouping users into specific roles. On a third pass, we may discover that roles are a good start, but they do not fully express our needs.

For example, imagine we were building a business system for a large entity with hundred of satellite offices. Although our business process may be standardized, each office may have enough variation such that a “clerical processor” at one branch has a drastically different role that a “clerical processor” at another office. Bob, a “clerical processor” in the large satellite office may need to be able to do tasks A & B, while Sue, a “clerical processor” in the small satellite office may need to perform tasks A, B, C, & D. The scenario can be further complicated as the number of satellite offices grows, with subtle differences across the entire organization.

In analyzing the business processes and individuals interacting with these processes, we often find this scenario is more common than not. We also find the stakeholders like the idea/concept of a role, but understand the role is too broad of a classification to capture the true complexity within their organization without creating hundreds of roles. As a result, we often introduce a concept of permissions, where roles (by default) have certain associated permissions. This alone does not solve our “hundreds of roles” problem, so we often discuss the possibility of users belonging to multiple roles, with the capability of deviating from a specific role’s default permissions in a customized manner, if necessary.

Coming back to my original point, our teams makes multiples passes to groom a backlog, with focus on the “As a user…” section to help us identify who will be using the system.

Back to big “A” Agile world, this approach is not necessarily the most efficient. In fact, many Agile organizations would say, start with “As a user…”, develop that functionality, ignoring a role/individual, and when we come back to review the system with our stakeholders, they can introduce the concept of only a subset of our users can perform an action. Only at that time should we consider developing a role-trimmed functionality.

In reality world, we rarely just get the generic case to start with – in fact, stakeholder’s time is a valuable commodity. As a result, we spend fewer (but larger) blocks of time discussing a product backlog. As a result, our conversation naturally drifts to discuss “who exactly” may be interacting with our solution. Yes, this may not result in true iterative development, but this approach seems to work well for our team.

I want to…

The second part of the user story, “I want to [action]” identifies the single activity the individual wishes to perform within our solution. An important aspect to note is the “single action” – not multiple. For example, a user story may ready “As a user, I want to view my account balance and print my transaction details…”. This user story describes two different actions. As a result, we should decompose this story into two separate stories, each based upon a single action: “As a user, I want to view my account balance..” and “As a user, I want to print my account balance…”.

Decomposing stories into separate pieces based upon actions performed is important for many reasons. First, it creates a more organized backlog, giving stakeholders the visibility to understand the quantity and size of individual efforts. Second, it allows stakeholders to selectively prioritize individual actions separately, i.e., it may be more important to view an account balance, as opposed to printing transaction history. Third, keeping these actions separate allows the project team to deliver one user story right now, and save the second story (based upon business value and priority) to a later date. This can help accelerate a product’s release based upon the minimal viable product required to get a solution to market. Fourth, developers have the ability to work on each user story in parallel, maximizing their efficiency.

So that…

The third part of the user story, “so that [business value] identifies the reason(s) why we are talking about a feature. Often times, I have seen teams leave off this portion of a user story, but in doing so, you miss a critical component of understanding why this user story is important to the business. Articulating the business value of a user story is the most difficult part of a user story, which is why it is often skipped. Many product teams I’ve worked with have struggled at this step, and the business often responds with, “because I said so.” As a consultant, I understand the difficulty of establishing “why”. I also understand there is a delicate balance of pushing your clients too hard when they say “because I said so”. I often explain the importance of establishing the business value, so we can better appreciate what is important to the business, and later prioritize the product backlog. Without establishing the business value, every user story within the backlog is equal in value, and choosing the right user story to deliver in a sprint becomes more difficult, which can lead to us not delivering the right functionality at the right time that maximizes the use of our time throughout a project’s lifecycle.

Keeping this in mind, however, the consultant answer is always, “it depends.” I want to serve my customers to the best of my abilities, while providing them maximum value, within the constraints they deliver. As a result, drawing a hard line in the sand around the requirement of proving a business value for every user story isn’t always a reality. Some of my great customers get “it,” and are energized by the conversation and understand the importance. Some of my great customers also get “it,” and are appreciative that we can work in the confines of their constraints (which is often time). All of my customers are grateful that we are willing to move forward with flexibility, without shutting down and complaining or in a passive-aggressive manner.

Other real world advice

I’ve talked a lot about big “A” Agile world, which is the island of perfection. Nobody lives there. We live in reality – a small subset of idealism – one that constantly changes. In big “A” Agile world also live user story purists, who insist upon the “As a [role/individual], I want to [action], so that [business value]” is adhered to at every moment. I’m not a user story purist, and don’t advocate with every project team that we adhere to this format at all times. Instead, I introduce this format to new teams. I ask the new teams to start at this baseline. As the team matures, and their understanding of the agile process grows, we may decide to drift. In our retrospectives, we discuss what’s working for us, and what isn’t working for us. Some very successful teams have been more lean in their story writing, moving from the standard for to no form at all. For example, “As a user, I want to view my account balance, so I can understand how much money I have in my account” will only be represented by the user story title of “Account – View Balance”. Neither format is wrong or right. What I stress to my teams is they should focus on what is right for them at this time, and own the process we decide upon as a team.

Save Yourself Some Time

Early user story writers often write “As a [role/individual], I want to be able to [action], so that [business value].” This story format is absolutely acceptable; however, it can be shortened by removing the “to be able to”. “I want to…” is a shorter form and projects the same meaning.

More Information

By design, user stories are intended to be ambiguous – they should encourage additional conversation, forcing project team members to get up out of their seats, explore the world around them, and visit with a stakeholder. Again, agile is about face-to-face communication, individuals, and interactions.

Despite the intent of ambiguity within a user story, my team prefers to provide more details in the user story body. We use Microsoft’ Team Foundation Server (TFS) to manage our project backlogs, and there is a large space for us to record additional information. We do not necessarily look to fill out his information at the moment we write each user story, but we target to develop and refine this information as the project progresses. The following compose what we considers as “more information” that is often found in our user stories.