An Argument for Comprehensive User Stories

23 April 2012

Shylesh Mysore
Mphasis Corp

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.

Article Rating

Current rating: 0 (0 ratings)

Comments

Michele Cresmen, CSM, 4/24/2012 8:26:29 AM
While your position is eloquently stated, I have to disagree. When the team commits to a story, they commit to it with the current set of acceptance criteria to guide them. Yes there are conversations, but you seem to have the belief that once the story is done, the functionality will never be revisited. You want to have a "complete" story so that the work to code it will be "complete" when it's done.

One of the strengths gained from adopting an agile mindset is the realization that - PO's and users will have new ideas and understanding when they *see* something. To ask them to create comprehensive "done" stories is a throwback to the belief that they know everything up front. There's less reluctance by the team to change because they thought it was fully documented what they needed to fulfill.

For your scenarios, my recommendation is...start a 2nd story that adds the additional acceptance criteria as you find it. It's an addition to what the team committed to in the first place and if they have time in the sprint to incorporate it, then that's their choice. As the team works on the story and has clarifying conversations where new acceptance criteria is found, to expect that they will have to include the new AC in the current sprint is just as bad as having the PO add criteria on the last day of the sprint during the demo and saying they won't accept the story until that new criteria is complete. If that happened during the demo, wouldn't you have them create a new story with the additional criteria and add it to the backlog?


One other comment, when a story has so much included with it, people will look at it and believe it's "complete." For those of us coming from a more traditional, big-up-front-planning methodology, we know that this is a fallacy. Users and PO's will rarely be able to create complete requirements up from the start and to expect them to is unrealistic and sets up the PO and the team for disappointment.
Charles Bradley - Scrum Coach, CSP,CSM,CSPO, 4/29/2012 2:56:53 PM
Shylesh, what I think you are trying to get to here is something along the lines of "The more user story detail you know up front, the better." If that is the case, I think your message is excellent, but might have gotten lost in the details of the article.<br>

I also think that what you are trying to describe is very similar to the "Specification By Example" technique of story testing. In essence, the more examples you identify up front (in backlog grooming or before works begins), the better. I totally agree with your sentiment about trying to identify happy, sad, and bad paths up front. <br>

I also didn't like your tone towards documents. I'd prefer user stories have more conversations and confirmations and a lot less documentation. While your team might have done just that, I didn't get that impression. OTOH, as someone who has written on and presented on User Stories extensively, I understand it is VERY difficult to describe a highly contextual and verbal practice in a written article like yours.

I greatly applaud you for your sentiment and your efforts... I'm just hoping people like you and me can find better ways to express ourselves! (I struggle with it too.)

Chris Fortuin, CSP,CSM, 5/4/2012 12:20:51 AM
Dear Shylesh,

Great work but I have to disagree with your conclusion of having more comprehensive stories because I still believe they smell comprehensive documentation (my observation: the comprehensive story doesn't fit my index cards ;-) ). Hence, IMHO the lack of acceptance test and/or underestimating the stories is not the cause of not delivering business value. The solution is to continue using short stories and take full advantage of our agile practices like velocity based planning (velocity is our "the great equalizer" to callibrate point estimates and avoid wasting time on effort estimates), test-driven development (to decompose user acceptance tests during the sprint as many small automated unit/functional tests and avoid wasting time with the product owner) and keeping WIP small (the team should avoid having many/all stories incomplete at the end of a sprint).
Charles Bradley - Scrum Coach, CSP,CSM,CSPO, 5/4/2012 5:40:18 PM
+1 to Michele's statement above. I cover the topic of handling mid-sprint scope changes here: "Handling Scope Changes Mid-Sprint" http://www.scrumcrazy.com/Handling+Scope+Changes+Mid-Sprint <a href="http://www.scrumcrazy.com/Handling+Scope+Changes+Mid-Sprint"> Handling Scope Changes Mid-Sprint </a>
Albert Arul Prakash Rajendran, CSM,CSPO, 5/9/2012 4:52:38 AM
Sylesh,

It is a nice model to bring user stories however i am afraid to say that i disagree that, bringing comprehensive story card, makes the team as a do'rs not programmers. Yes your model will help testing team a lot in covering all scenarios but it also crubs the innovation of development.

Team at one point say we will develop what is asked nothing more. During sprint planning with just required details model, team ask these questions and also they come with many innovative ways to handle the requirement. Also as a Product Owners we also will receive more thoughts from team.
Mahmood Ali, CSM, 6/10/2012 3:48:34 PM
It seems to me that comprehensive user stories could be a plus from the perspective that it helps the team in better planning, better sizing and ensuring that the user's demands are met, particularly from the non-functional requirements point of view.

The term "comprehensive" in "comprehensive user stories" could be a scary to some. Maybe we can call it "complete" user story instead of using the term "comprehensive".
Shawn Samuel, CSM, 8/7/2012 10:55:53 AM
"In that sense, continue to identify the best or all possible business scenarios which would still make a user story INVEST-model compliant."

Respectfully, I must disagree. While the first example is clearly negotiable, the second example is a much more like a contract and is not negotiable. - In the first example, the team might realize that the last name field is for some reason a char(20), and this would come out in a discussion of the story, and the product owner might be fine with a 20 character last name, however if it is written as precise acceptance criteria (the second example), it leaves not room for discussion. On the same line, I find that very comprehensive stories falsely convey precision, which they do not actually have, and which can lead to teams assuming that the product owner thought of *everything*, and that they have nothing to contribute to the discussion of the story. I would rather have a team having a good discussion of a user story and getting on the same page, than a team assuming there is nothing to discuss as the product owner has handed them the detailed requirements.

You must Login or Signup to comment.