User stories, initially proposed for the agile management of IT projects, and particularly important in the business intelligence field.

Definition

A user story is a simple description of a need or an expectation expressed by a user, which is used in the software development field or in the design of new products to determine the functionalities to be developed. Source: User story, Wikipedia

The user story concept appeared for the first time as part of the implementation of a software engineering approach called extreme programming (XP). It is now commonly used in agile approaches. The Conducting a business intelligence project in agile mode page explains the benefits of using this type of project-management method in a business intelligence context.

Leaving aside the choice of project management methodology, which is not the subject of this page, the user story concept is of major interest for the formulation of functional needs. We will now show you why.

Structure of a user story

A user story is structured in the following way:

As a [type-user], I want a [functionality] in order to [purpose].

where:

  • type-user: must correspond to a clearly identifiable role / function (marketing manager, human resources director, sales manager, etc.). The description of the type-user should be consistent with the specified functionality and the nature of the decisions liable to be made.
  • functionality: this is a need in terms of the analysis of a phenomenon or of the performance of a process (customer satisfaction, sales performance, etc.). We shall not list the possible or necessary indicators here, but you should take note of them and put them in appendices for the indicator construction phase.
  • purpose: this involves explaining how the stated need assists the type-user with decision-making in order to achieve the objectives set by his or her company.

The eight mistakes to avoid

An initial approach to writing effective user stories requires the avoidance of the eight common mistakes listed below.

The functionality should assist with dashboard design

  1. Avoid functionalities that are not related to the analysis of dashboards:
    • carry out market research
    • conduct a financial analysis
    • develop a mobile application
    • adapt my advertising campaigns
  2. Avoid functionalities that fall outside the business intelligence context:
    • compare [my products] with those of other chains
  3. Avoid functionalities in the form of tools:
    • I want to obtain a tool for measuring customer satisfaction
  4. Avoid including multiple functionalities in a single story:
    • improve targeting […], develop the offering […], increase satisfaction […]
  5. Avoid functionalities which are the business objective

The purpose should lead to decision-making

  1. Avoid a purpose that is an objective rather than a decision:
    • to enable a five-fold increase in the quantity delivered
    • to be able to improve the quality of my delivery service
  2. Avoid a purpose that is a vague decision:
    • to improve the delivery quality
  3. Avoid multiple purposes
    • to enable the chain […], to better target […], to increase satisfaction […]

Quality criteria for a user story

The quality of a user story can be assessed by means of the INVEST model: Independent - Negotiable - Valuable - Estimable - Small - Testable. Certain criteria of this model are only applicable if a set of stories are assessed in the framework of a project rather than the quality of a single story that is not linked to any specific context.

INVEST model
INVEST model

What these different criteria mean:

  • Independent: a user story should not depend on the performance of another user story implemented during the same iteration.
  • Negotiable: it should be possible for the different stakeholders to negotiate a user story. This means that user stories must be clear and easily understood by everyone (from the client and final users through to the project management and client support functions).
  • Valuable: a user story should lead to decision-making. A story that leads to no improvement whatsoever in the performance of the company’s processes serves no purpose.
  • Estimable: a user story is sufficiently clear that its development time can be estimated.
  • Small: a user story should be written at the most atomic level in order to facilitate its development.
  • Testable: a user story should contain all the elements required to enable it to be tested.

Reading User Stories: comment bien les rédiger, by Margaux at Hubvisory, https://hubvisory.com/blog/user-stories-comment-bien-les-rediger/, accessed November 30, 2020.

Reading Splitting user stories – Why, When, How, by Alin Pandichi, https://mozaicworks.com/blog/splitting-user-stories/, accessed April 2, 2020.

Epic user stories

Certain user stories may be considered excessively long and irrelevant as they cannot be implemented during a single iteration.

Rather than rejecting them, ask yourself whether they could be used as epic user stories for the project, by combining several smaller stories.

Epic user stories provide an overview of the project without going into detail and enable the presentation of certain specific user stories in subsequent phases of the project.

What comes next?

In a second phase, depending on the users, the required functionalities and the decisions to be made, you must specify how you will meet this need. To this end, you will need to define: