Tuesday, March 19, 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…

A day in life of an AgileUX Practitioner: Personas

Posted by jc-Qualitystreet on 2011/03/08

Activity #2 of the Agile UX practitioner…
(See the Activity#1: Vision)

The Agile UX practitioner creates Personas collaboratively

A persona is a user-archetype, a fictional representation of target users you can use to help guide decisions about product, features, navigation, visual design…

Persona "Sophie" (for a french banking project) Contexts-Goals-Implications

Persona "Sophie" (for a french banking project) Contexts-Goals-Implications in an agile way. Personas workshop

Personas are an essential element of the product Vision envisioned at a strategy level. They represent the first sections of our Vision formula (from Geoffrey Moore): FOR (target for the product) …WHO (users’ needs), a key element of the famous elevator pitch.

The persona approach provides a team with a common and shared understanding of the users of a service or product (but also what they want, their behavior, their needs and expectations) in a very engaging format, easily linked to Agile User Stories.

In short, personas are a fantastic way to integrate real User Experience all along the product development project.

And this is the role of the Agile UX practitioner to  be the Personas promoter and to initiate their creation in collaboration with the Product Owner and the Team.

Create the Personas with Agile Teams

Everything starts at the beginning of the project, before sprint 1 (a sprint 0 or short exploration is an appropriate period for doing it). But, the persona approach requires mobilizing the entire team around it and should be envisioned collaboratively.

1 Prepare

  • Organize one or two workshops with the Product Owner  and various stakeholders in order to be aligned to the objectives and the approach, to identify data sources, to determine categories of people to interview (for example the core roles)
  • Inform the entire team of the process
  • Then collect data from various sources including user interviews.

2 Construct collaboratively

  • Analyze data (facts) in collaborative workshops using affinity diagram and identify variables then patterns
  • Create the Personas skeletons
  • Give birth to the personas (including storytelling, writting and visual design) using the format you prefer (formal or not)
  • Validate the results with various stakeholders
A Persona Template (more formal)

A Persona Template (more formal)

3 Communicate & Use

  • Include the Personas on the Information Radiator within the team environment
  • Link the Personas to User Stories
  • Use them as a prioritization tool (in the Product Backlog) and a designing tool (related to specific user stories)
  • If necessary, make a communication plan for marketing and sales activities: make a buzz!
Personas Ericsson Life in 2020

Personas Ericsson Life in 2020: Make the Buzz!

User Stories: hear the User Voice !

Posted by jc-Qualitystreet on 2009/11/12

User stories are increasingly used on Agile projects. This popularity is a very good thing. Goal and business oriented, their simplicity and a immediate focus on acceptance criteria make them terribly effective on design projects.

Once the 3C described (Card, Conversation and Confirmation) and INVEST criteria well understood, when the team and Product Owner start to discover their own stories, they often ask me if the « User Voice » format must be respected …
This format is the following:

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

A sentence in which,

  • The role is the one that makes the action and who benefits
  • The goal is the action executed
  • The Business value represents the benefits that emerge from the action

So, should we use this format ? My answer is definitely YES!

  • The « User Voice » gives meaning to the feature … why and for whom the team will develop the product
  • It is a step closer to a user experience approach, especially to the Personas method.The role is often a Persona, representing a concrete realistic and shared vision of the end user.
  • It is clearly ACTION and  GOAL oriented (so efficient to design products)
  • It justifies all the functionality of a business point of view, and requires the Product Owner and teams to systematically examine the value of each feature

My advice:
Give a  concise and significant title  to the User Story and then describe the user story using the « User Voice » format.

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