An Argument for Comprehensive User Stories

As Scrum practitioners know, a user story is a high-level requirement of a feature, provided from the perspective of a stakeholder who desires the new capability. These requirements enable the development and testing team to think about a solution and, thereafter, about size, estimates, and commitments.

A user story explains, from the consumer's perspective, what happens and why, and it ensures that the three C's (card, confirmation, and conversation) are covered.

What's the format of a user story?

In most cases, the user stories embraced by many teams follow the format below, but the defined acceptance criteria would be high level:

• Title: User story title
• As a: This describes who requires this story.
• I want to: A description of what is required. A statement of the problem (opportunity) to be solved, not the solution.
• So that: A description of why this story is needed. What is the business benefit if this problem is solved? It's imperative that this section of the card be completed so the team can focus the user on why he or she is asking for this feature/functionality.
• Acceptance criteria: The acceptance criteria describe the tests/conditions that need to be passed in order to determine when the story is complete.

What is a comprehensive user story?

A comprehensive user story has acceptance criteria that cover all possible functional scenarios or conditions needed to satisfy the user requirements. In development and testing terms, this means defining positive and negative scenarios.

How do "comprehensive" user stories differ from "short" user stories?

Let's view this through a simple example, considering "registration" functionality to an Internet site or an intranet. The functionalities that would exist in this example are:

• The ability to enter basic data, such as first name, last name, email ID, street address, city, state, zip code, country
• The ability to save or cancel the user data
• The ability to send a notification (email) to mail ID

The product owner (PO) next has a set of activities to achieve: converting the functions to user stories. The titles of the user stories would be based on these functions:

• Define registration data for each customer or user
• Save the registration data for each user
• Send a notification to each user, with user ID and password on successful registration
• Send a notification of failure of registration

Considering the user story, "Define registration data for each customer or user," the requirements of this user story would look like the definitions below when defined as a short story:

Short user story

Define personal data for each customer or user to register

As an . . . Internet user,

I want . . . to be able to enter my personal information for registration

So that . . . I get to register for an Internet application.

Acceptance criteria:

AC1. User needs to enter data for mandatory fields, identified by asterisks.

AC2. User needs to enter a valid email ID.

AC3. If user clicks "Save," then data should be saved.

AC4. If user clicks "Cancel," then data entered by user is refreshed and the fields are cleared.

The same requirement when written in a comprehensive way is shown below:

Comprehensive user story

Define personal data for each customer or user to register

As an . . . Internet user,

I want . . . to be able to enter my personal information for registration

So that . . . I get to register for the Internet application.

Acceptance criteria:

AC1. User needs to enter data for mandatory fields, identified by asterisks.

AC2. First name should not exceed 25 characters; do not allow field editing beyond 25 characters.

AC3. If "First Name" is blank, do not allow user to enter data in other fields; display an error message. (Refer to Exception document, section Registration 1.1, for message.)

AC4. Last name should not exceed 25 characters; do not allow field editing beyond 25 characters.

AC5. If "Last Name" is blank, do not allow user to enter data in other fields; display an error message. (Refer to Exception document, section Registration 1.2 for message.)

AC6. If "Email ID" is blank, do not allow user to enter data in other fields; display an error message. (Refer to Exception document, section Registration 1.3 for message.)

AC7. Check for email ID validity, for proper format. If not proper format, then display an error message. (Refer to Exception document, section Registration 1.4 for message.)

AC8. If user clicks "Save," the data should be saved.

AC9. If user clicks "Cancel," then data entered by user is refreshed and the fields are cleared.

• All mandatory fields checks can be client-side validation.
• Refer to Exception document for all exception messages.
• The application should be accessible from multiple browsers, such as IE, FF, Google Chrome.
• The application should be compliant for mobile devices.

Note: Specifics highlighted as bullet points can be drafted either at each story level or at the document level for a group of user stories.

Do we need a comprehensive user story?

The comprehensive user story helps team members, irrespective of their expertise in domain skills, to understand the problem statement and make a correct analysis. It further helps in identifying and defining tasks appropriately, along with creating approximate estimates. Defining a comprehensive user story ensures that individual team members and the whole team provide the commitments for a sprint based on tasks to do, not based on assumptions.

Here are a few key observations about what can happen when a user story is not comprehensive:

1. The lesser details will reduce the user story size.
2. The team will overestimate the task based on assumptions (buffer the estimates), and it will identify additional scenarios of which a few might not be relevant to the business at hand.
3. The team will commit based on a short set of requirements (as defined in acceptance criteria for a user story), which might not point to the required solution. By the time the team and product owner identify required scenarios, the team is left with less capacity to satisfy the needs of the product owner.
4. Overall, the team is either undercommitted or overcommitted for any sprint.

Additionally, the key artifact that covers business requirements are the story boards (user stories). This artifact is key for Scrum teams trying to identify the list of do's and don'ts and hoping to ensure that the deliverable will satisfy requirements. Based on this, detailed user story preparation is significant, and it would have less or no scope in identifying the missing business scenarios through negotiations.

The other artifacts, such as design and wireframes, are based on the requirements defined in the user stories, and these would act as reference documents (not explaining the business side of story). That is, these artifacts provide an approach the developers and testers need to take in order to execute the user requirements successfully.

One of the key points of the Agile Manifesto is, "Working software over comprehensive documentation." This doesn't call for either high-level or less documentation in the artifacts, but it is a means of limiting multiple documents used to define a project (they were the norm when implementing software in the traditional way).

In that sense, continue to identify the best or all possible business scenarios which would still make a user story INVEST-model compliant.

What are the benefits of comprehensive user stories?

The user story (or stories) is a key document the team needs to understand the business requirements. The more information is made available in the user story, the fewer issues the team will need to overcome, especially in sizing, assumptions, missing scenarios, estimations, and commitments. Why?

• Planning: The planning meeting can be shortened, as the majority of team queries would be answered in the user stories. There is less room for assumptions and enough time for an early start in development and testing work.
• Sizing: The team is aware of the amount of work it needs to achieve, as well as the complexity and effort involved. So the sizing in the story points would be correct, neither an assumptions-based exaggerated number nor an underestimate.
• Commitments: Detailed requirements reduce the team's need to identify new scenarios, lessen the number of queries to answer, reduce the chances of requirements increasing or decreasing, and don't produce a product or application that's based on assumptions. The commitments made by the team, both preliminary and final, are more accurate.
• Review: The review sessions cover the defined acceptance criteria, leaving lesser scope for the product owner to review the product based on assumptions. Any changes identified during the review would move into product or release backlog stories.

These benefits can be observed in an example based on the project experience of a telecom vendor. This is based on two different sprints for two different user journeys (functional flows), which had user stories defined in both short and comprehensive styles.

Scenario 1: Defining short user stories

1. The team usually spends one-half to three-quarters of a day for task breakdown (as part of planning sessions), but an additional two days are spent during the sprint. Reason: During the sprint, the team identified additional scenarios to cover as part of development and testing. These additional tasks were discussed with the product owner for acceptance.
2. The sizing and commitments were based on an initial size of 525 story points, and later the size increased by an additional 200 story points (totaling 725 story points). Reason: The additional tasks identified increased the acceptance criteria, and this led to an increase in size.
3. The task-based efforts increased by 40 percent from the initial estimation of 2,000 hours.
4. The increase in efforts altered the sprint deliverable, because the integration testing couldn't be accommodated during the sprint as the functionality developed was incomplete. Reason: All the committed user stories were not delivered as initially committed, and additional acceptance criteria added were not developed. This blocked the end-to-end functional testing.
5. The backlog priorities were altered to accommodate additional acceptance criteria identified in the very next sprint.

Observation: The view might be that addition of acceptance criteria constitutes the reason for the increase in size and efforts. But the fact is that, at end of the sprint, the deliverable had no business value. If the user story had been comprehensive, the team would had ensured the commitments and deliverable.

Planning: Efforts increased 50 to 75 percent

Sizing: Increased by 40 percent

Estimation: Increased by 40 percent

Commitments: 10 percent of initial commitments reduced

Business value delivered: None (the deliverable had no business value)

Scenario 2: Defining comprehensive user stories

1. The team spent half a day for task breakdown (as part of planning sessions).
2. The size estimated for work was 217 story points.
3. The efforts estimated for all tasks were around 610 hours; the actual efforts expended by team were 632 (an increase of 3 percent, small when compared with 40 percent above).
4. The team also delivered additional work due to available capacity, since new scenarios did not arise leading to requirement changes.
5. The sprint was successfully completed, with all functionalities tested, and the result was reviewed and accepted by product owner.

Observation: How did the team pick up additional work?

• The analysis of requirements by the team was perfect, and no new tasks were identified during task breakdown or during task execution.
• The size of work (story points) was correct and did not change.
• The estimation (in hours) was correct, with no new additions.

Planning: No increase in efforts

Sizing: No increase

Efforts: Increased by 3 percent

Commitments: 15 percent increase, as additional work was picked up

Business value delivered: 100 percent (including additional work)

Remember, if the product owner believes the user stories are detailed, then experiment to make them better by making them more comprehensive. As the saying goes, Agile is a journey, one that's all about continuous improvements.