Friday, March 1, 2024

Subscribe to the RSS Feed

User Story Checklist… Be Ready, be EFFECTIVE!

Posted by jc-Qualitystreet on 2012/03/01

The art of the specification in a agile context is above all collaborative. It’s also a matter of behavior.

As you know I like user stories. The format is a good way to express a requirement and to initiate the conversation between a Product Owner (supported or not by UX specialist, Business Analyst…) and the Team.

But of course, this short description, usually in one or two lines, is not sufficient to enable a Team to develop the functionality described… (see agile PROTOTYPING)

A generic template that must be adjusted to your own conditions of readiness

A generic template that must be adjusted to your own conditions of readiness

In short, the idea behind this precious checklist (inspired by Lisa Crispin and Janet Gregory‘s book) is to facilitate the job of the Product Owner.

With this checklist, the Product Owner identifies the key elements that must come (in his context) with a specific User story. For example, these important test cases must be envisioned or a link to UX stuff, wireframe of the screen, UI library or a prototype must be provided.

This is also the place where you can start describing required business rules (the business rules paragraph was crucial for financial and supply chain projects I was involved in and we linked it to an ATDD approach).

The Product Backlog Refinement (the » forgotten » 5th Scrum ceremonial for grooming activities 🙂 ) or other dedicated collaborative workshops are good opportunities to work on the checklist and to make sure that a specific user story will be ready to be taken and developed during the next sprint.

Product Backlog Refinement Agenda

Product Backlog Refinement Agenda

Then, several days later, first day of the new sprint, the sprint planning part I (scope definition) will be used to confirm the various elements, especially the conditions of satisfaction, and the engagement of the Team to develop, by the end of the sprint, the user stories discussed.

Remember: feedback and collaboration!

10 strategies to split large user stories

Posted by jc-Qualitystreet on 2011/04/19

A user story is a requirement of the system to be developed, a brief description of a feature as viewed by the user (Role → Goal), very popular on Agile projects.

« As a customer, I want to book a train ticket to go to Paris »

User Stories are usually associated to the 3C rule, quality criteria (INVEST) and the « User Voice » format

As a <User Role>
I can <Goal>
So That <Business Value>

user stories INVESTEd... goal oriented and customer-centric

user stories INVESTEd… goal oriented and customer-centric

Each user story must be estimated (by the team) and prioritized, but also SMALL ENOUGH to be delivered in a sprint (usually smallest teams take at least 3 stories per sprint). This is a necessity if you want to observe real benefits in terms of value delivery, visibility, flexibility, feedback and continuous improvement.

During my agile coaching activities, I am regularly asked to help the team and Product Owner to split user stories into smaller ones.

Here are the 10 strategies I use to effectively split large user stories:

1 Steps of a workflow

The user performs a task according to a well-established workflow. The large user story is split according to these steps in order to be developed incrementally. Each step has its own user story.

2 Scenario

By splitting a user story by scenario, you get a User Story for the main success scenario and other user stories for any errors or alternative paths:
when x happens, then…
when…, then

3 Sequence in a scenario

The case is more precise, you divide the story according to a specific sequence in a scenario.


4 Operations

Splitting a user story by operations is often the most obvious way to decompose. A CRUD (Create, Retrieve, Update, Delete) feature is a good example. Separate the CRUD or group two operations in a user story may be appropriate … to create an account, to view it, edit it and delete it.

5 Size or type of data

Pretty obvious too. You divide large user stories according to the type of object (e.g. various account types, messages in English, French, Spanish…)

6 Type of input, output or configuration

Variations in terms of material or not, on configurations but also in terms of input means or User Interface can lead to new and smaller user stories.

7 Persona or role

This time, you choose to break down the user stories based on the role or the persona who will use the product. This is a very good option easy if you use the user voice format or the Persona approach. The story mapping activity is a good way to visualize it.

8 Level of knowledge

The level of knowledge acquired on a feature is a good criterion of decomposition… You can get a specific story for what is known, another one for the unknown (leading to a spike and exploration activity)

9 Level of complexity

For example a user story can describe a feature in the simplest way of implementation, others will follow by a greater level of complexity or detail.

10 Level of quality expected

Performance, Security, Usability … these non-functional requirements are usually described in the elements of conversation, of a specific user story. There are conditions of satisfaction, but they can also help distinguish between these user stories (eg display it in less than 60 seconds, less than 30 sec; data in real time or not …)

Illustrations will be added progressively. If you want to participate, please submit your comments with your example and strategy number…

Use cases – User Stories: so precious but not the same !

Posted by jc-Qualitystreet on 2009/01/23

Use cases and user stories are two popular ways to capture functional requirements. They’re both goal-oriented (a very good thing), can be discovered during user / customers workshops, can be easily combined with UX activities, and are used in Agile contexts.

Use cases and user Stories look similar; actually, they’re different. Here is the list of 14 major differences I’ve observed:

  1. A user story is a brief description of functionality as viewed by the user (Role → Goal); it doesn’t model the interaction between the actor and the system, what the use case does. A user story is not a sequence of actions.
  2. A user story is short and consist in one or two sentences written in the language of the user (example: As a recruiter, I can submit job vacancies). A role and a goal, then it is discussed. A use case is heavier, richer in information: goal, summary, actor, precondition, trigger event, main success scenario and extensions (alternative paths, errors …). Use case is (too much) detailed.
  3. A user story is smaller and can finally be seen as a part of a specific use case: the main success scenario or an extension
  4. User stories are used for planning. They play a major role in project estimation and planning (via story points and velocity). Use cases are not used for planning, even if you can use « use cases points » technique to estimate project size.
  5. User stories emerge faster than use cases; use cases require more time for analysis and writing
  6. User stories are more readable than use cases; use cases usually belong to a large word document, often poorly written and difficult to read even in a structured template
  7. User stories are easier to maintain than a 150 pages Use cases Document
  8. User stories are based on verbal communication and rely on collaboration, discussion and proximity to clarify details. Use case is a textual model (associated with diagrams): every thing is written !
  9. User stories are in theory written on cards (remember the 3 C rule: Card, Conversation, Confirmation): they’re not intended to be archived unlike use cases.
  10. A user story must be implemented and tested in one iteration; a specific use case can be implemented in several iterations: main success scenarion on iteration 1; extensions in Iteration 2 and 3 …
  11. User stories can be more easily written by a user or customer; most of the time use cases are written by user proxies (BA, Consultants …)
  12. User stories contain acceptance tests (validation criteria) written on the back of the story card; use case not: tests cases are created in a separate documentation
  13. Use cases provide a more holistic view of the system: precondition, UC diagram, sub use case. Linking user stories is less obvious. This is also a reason why UX and IxD activities are so important in agile contexts !
  14. Finally, Use cases and user stories were originally associated with two different methodologies (Unified Process vs eXtreme Programming). But both can be used with agile methods and unified process !

My preference:

I have almost a ten years experience with use cases. Alistair Cockburn’s book « Writting effective use cases » used to be my bible for years… but now, my preference tends to go to user stories model. And this is usually my recommendation to Agile Teams.

Why ?

  • User stories focus on what is really important
  • User stories are more appropriate for collaboration
  • User stories can perfectly be combined with UX activities (Personas, Storyboard, Wireframes):
    User stories + UX artifacts = Just enough