Summary of User Stories: The Three "C"s and INVEST

User Stories

We provide in-depth simulation-based training for Product Owners and a large portion of that training is focused on user stories.  Please consider our public Certified Scrum Product Owner training, or bringing us on-site for customized training for writing user stories.

TL;DR Become familiar with the “User Story” approach to formulating Product Backlog Items and how it can be implemented to improve the communication of user value and the overall quality of the product by facilitating a user-centric approach to development.

Consider the following…

User stories trace their origins to eXtreme Programming, another Agile method with many similarities to Scrum. Scrum teams often employ aspects of eXtreme Programming, including user stories as well as engineering practices such as refactoring, test-driven development (TDD) and pair programming to name a few. Check out our Agile Software Developer learning events for training on these engineering practices.  For now, we will concentrate on the capability of writing good user stories.

The Three ‘C’s

A User Story has three primary components, each of which begin with the letter ‘C’:

Cardⁱ

The Card, or written text of the User Story is best understood as an invitation to conversation. This is an important concept, as it fosters the understanding that in Scrum, you don’t have to have all of the Product Backlog Items written out perfectly “up front”, before you bring them to the team. It acknowledges that the customer and the team will be discovering the underlying business/system needed as they are working on it. This discovery occurs through conversation and collaboration around user stories.
The Card is usually follows the format similar to the one below

As a <user role> of the product,

I can <action>

So that <benefit>.

In other words, the written text of the story, the invitation to a conversation, must address the “who”, “what” and “why” of the story.

Note that there are two schools of thought on who the <benefit> should be for. Interactive design specialists (like Alan Cooper) tell us that everything needs to be geared towards not only the user but a user Persona with a name, photo, bio, etc. Other experts who are more focused on the testability of the business solution (like Gojko Adzic) say that the benefit should directly address an explicit business goal. Imagine if you could do both at once! You can, and this will be discussed further in more advanced modules.

Conversation

The collaborative conversation facilitated by the Product Owner which involves all stakeholders and the team.

As much as possible, this is an in-person conversation.

The conversation is where the real value of the story lies and the written Card should be adjusted to reflect the current shared understanding of this conversation.

This conversation is mostly verbal but most often supported by documentation and ideally automated tests of various sorts (e.g. Acceptance Tests).

Confirmation

The Product Owner must confirm that the story is complete before it can be considered “done”
The team and the Product Owner check the “doneness” of each story in light of the Team’s current definition of “done”
Specific acceptance criteria that is different from the current definition of “done” can be established for individual stories, but the current criteria must be well understood and agreed to by the Team. All associated acceptance tests should be in a passing state.

INVESTⁱⁱ

The test for determining whether or not a story is well understood and ready for the team to begin working on it is the INVEST acronym:

I – Independent

The solution can be implemented by the team independently of other stories. The team should be expected to break technical dependencies as often as possible – this may take some creative thinking and problem solving as well as the Agile technical practices such as refactoring.

N – Negotiable

The scope of work should have some flex and not be pinned down like a traditional requirements specification. As well, the solution for the story is not prescribed by the story and is open to discussion and collaboration, with the final decision for technical implementation being reserved for the Development Team.

V – Valuable

The business value of the story, the “why”, should be clearly understood by all. Note that the “why” does not necessarily need to be from the perspective of the user. “Why” can address a business need of the customer without necessarily providing a direct, valuable result to the end user. All stories should be connected to clear business goals. This does not mean that a single user story needs to be a marketable feature on its own.

E – Estimable

The team should understand the story well enough to be able estimate the complexity of the work and the effort required to deliver the story as a potentially shippable increment of functionality. This does not mean that the team needs to understand all the details of implementation in order to estimate the user story.

S – Small

The item should be small enough that the team can deliver a potentially shippable increment of functionality within a single Sprint. In fact, this should be considered as the maximum size allowable for any Product Backlog Item as it gets close to the top of the Product Backlog. This is part of the concept of Product Backlog refinement that is an ongoing aspect of the work of the Scrum Team.

T – Testable

Everyone should understand and agree on how the completion of the story will be verified. The definition of “done” is one way of establishing this. If everyone agrees that the story can be implemented in a way that satisfies the current definition of “done” in a single Sprint and this definition of “done” includes some kind of user acceptance test, then the story can be considered testable.

Note: The INVEST criteria can be applied to any Product Backlog Item, even those that aren’t written as User Stories.

Splitting User Stories:

Sometimes a user story is too big to fit into a Sprint. The simplest approach to splitting is to look for a literal or implied conjunction “and” or “or” in the text of the story and then create two or more new stories from the parts around the conjunction.  For example: “As a user I can do one thing and another thing so that I’m happy.”  That can be split into “As a user I can do one thing so that I’m happy” and another story “As a user I can do another thing so that I’m happy.”  Some additional ways of splitting a story include:

• Split by process step – every step is a new user story
• Split by I/O channel – each I/O channel becomes a separate story
• Split by user options – the options become the user stories
• Split by role/persona – each role/persona becomes a separate story
• Split by data range – every significant range is a new user story (e.g. 0, 1-9, 10-99 or last year, this year, next year).
• Split by CRUD action – create, read, update, delete (only applicable if each action has business logic and they are asymmetric).

WARNING: Do not split stories by system, component, architectural layer or development process as this will conflict with the teams definition of “done” and undermine the ability of the team to deliver potentially shippable software every Sprint.

There are many additional methods of splitting user stories.

Personas

Like User Stories, Personas are a tool for interactive design. The purpose of personas is to develop a precise description of our user and so that we can develop stories that describe what he wishes to accomplish. In other words, a persona is a much more developed and specific “who” for our stories. The more specific we make our personas, the more effective they are as design tools.ⁱⁱⁱ

Each of our fictional but specific users should have the following information:

Name
Occupation
Relationship to product
Interest & personality
Photo

Here is a simple example persona:

Joseph Pike

Age: 26, New Graduate

Lives in Guelph, Ontario with parents

Joseph studied sociology for three years then switched to business. He has an MBA from a second-tier business school. Joseph grew up in Guelph, Ontario and loves to travel.

Joseph is looking for an entry-level position in a larger corporation for marketing or sales. He doesn’t have many of his own contacts on LinkedIn and so has decided to try using job search sites and apps.

Joseph loves thrillers and horror movies and is not in a serious romantic relationship.

(stock photo not included)

Only one persona should be the primary persona and we should always build for the primary persona. User story cards using personas replace the user role with the persona:

<persona>

can <action>

so that <benefit>.

i The Card, Conversation, Confirmation model was first proposed by Ron Jeffries in 2001.

ii INVEST in Good Stories, and SMART Tasks. Bill Wake. http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

iii The Inmates are Running the Asylum. Alan Cooper. Sams Publishing. 1999. pp. 123-128.

Please join us at one of our training sessions to learn more about user stories.  Please consider our public Certified Scrum Product Owner training, or bringing us on-site for customized training for writing user stories.