INVESTing in good stories

In April, we shared an overview of the User Stories element of the Michigan Agile Philosophy (MAP).  That post provided an overview of how stories use estimates, acceptance criteria and description to frame a discussion around work.

To help continue our improvement regarding story writing, here are a few things that might be helpful:

INVEST

A good user story uses the “INVEST” model:

• Independent. Reduced dependencies  = easier to plan
• Negotiable. Details added via collaboration
• Valuable. Provides value to the customer
• Estimable. Too big or too vague = not estimable
• Small. Can be done in less than a week by the team
• Testable. Good acceptance criteria

We've put together a one-page Invest tool that helps to walk through this model with some details and things to watch out for.  Print this out, keep it nearby and use it often when collaborating on stories. 

Comparing User Stories, Use Cases and Requirements*

The difference between user stories, use cases and requirements is one of perspective.  If we consider the work we are doing as affecting systems and their users, we see clear differences.  

• Requirements describe the work from the perspective of system operations - how do we limit the interpretation to be sure the system does what it should do. 
• Use Cases describe the work from the perspective of the users and how they interact with the system.  Use cases describe - often through text and diagrams - a call-and-response format of what a user does to interact with a system. 
• What makes User Stories unique is their focus on customer value.  They loosely describe  the specification in order to foster a higher level of collaboration with the team.  The acceptance criteria describes the more traditional requirements and use cases to be met, but secondary to the value of the customer. 

Stories != Requirements

A story is not a highly documented requirement of what the user wants, it's a reminder to collaborate about the topic of the user story.  The documentation is secondary to the collaboration.  Stories are just a tool to support underlying values of agile - just-in-time definitions and collaboration.  

Comparison Example

Problem Statement

The client has requested the ability to search for health care providers by provider specialty within a doctor selection site. 

Sample: Requirements Statement

The provider search screen shall provide the ability to search for providers by provider specialty.

Sample: Use Case

The client selects provider search.

The system retrieves a predefined list of provider specialties and populates the specialty list. The system displays the provider search mechanism.  

The client selects a provider specialty and initiates the search.  

The system retrieves a list of providers that match the provider specialty search. [Alt 1]

The system displays a list of providers that match the search. [Alt 2]

End use case

Alt 1:  If there are no matches, the system displays a message indicating that no matches were found.  End use case.

Alt 2:  If there are more matches than the user can view, the system will provide the capability to display multiple pages.

Sample: User Story

Title:  Search for providers by provider specialty.

Description:  As a provider search user, I need the ability to search for providers by specialty so that I can more efficiently refer patients to specialists.

Acceptance criteria:  

1. The provider search mechanism has the ability to enter a specialty.
2. The specialty search will have a list of provider specialties from which to select.
3. Searching via the provider specialty will return a list of matching specialists or a message indicating that there are no matches.
4. If there are more results than can fit on one page, the system will provide the capability to view the list in pages or sections.

So? 

User stories aren't inherently any better or worse that use cases or requirements.  It's the individual or team that makes the technique work.  However, within MSIS one of our core values is collaboration and the user story format incentivizes, prompts, and ultimately rewards the discussion around the work to be done.  We believe that user stories allow us to do things that align with our definition of success: (1) collaborate, (2) focus on customer value and (3) minimize non-value added work.  

Thanks!
Michael Warden

jwarden@umich.edu | 734-546-2929

* This section borrows heavily from a great post by William Nazzaro and Charles Suscheck of Process Synergy, LLC who wrote a member article on Scrum Alliance in April 2010 titled 'New to User Stories?'