Often it is believed that a perfect User Story is written like: “As a user X I want to do Y So I can achieve Z”. Some people also believe that this is all what needs to be written down for a development team to create the right results.

Therefore, it is not surprising that most development teams have a hard time estimating stories and that their velocity fluctuate.

Below some tips to improve your User Stories so you will get the functionality you want and your development team is able to create the right value:

1. Create a Short Name

Create a short name for each User Story, so you are able to recognise a story easily on the backlog and so you are able to have efficient communication about your story. 

2. Use the User Story Syntax

Use the User Story Syntax “As a user X I want to do Y so I can achieve Z, as the introduction to the description of the desired functionality. The User Story Syntax ensures that the to be developed functionality will be used by somebody and that it wil generate some value for this person.

  • Who your stakeholder will be : (user X)
  • What kind of functionality he wants to have (Y)
  • Why he wants to have it thus the added value (Z)

3. Add Additional context

Because the User Story Syntax just creates a high level understanding about the desired functionality it is a good practice to add additional context. For example some business context about the situation where the functionality is needed, or to create insight in the bigger picture. Really important to the business context is to write down who requested the functionality so you are able to contact this person again later on if needed.

4. Define Succes

Really important part of creating Perfect User Stories is to define the Success Factors. These Success Factors should be able to proof the implementation was a success and created the expected value. Examples of SuccessFactors for Perfect User Stories are:

  • Indication of the amount of time which will be saved
  • Increase in number of sales.
Succes

5. Add Acceptance Criteria

Add Acceptance criteria to the User Story. Acceptance Criteria will be the requirements which needs to be fulfilled in order to finish the release the functionality. The acceptance criteria can be used as input for creating test cases. And don’t forget the non functional acceptance criteria

6. Create Unique Identifiers

Create unique identifiers for your Acceptance criteria so you are able to reuse them if possible (for example for non functional acceptance criteria) this saves you a lot of work.

7. Identify data 

Identify which data is necessary for execution of the functionality. This ensures that your developers will know what kind of integrations are necessary to complete the story. This will also make you aware of possible privacy risks in an early stage.

8. Determine Impact

Define Impact

In a Perfect User Story is described which impact on other systems and business processes can be expected. For example which process needs to be changed, which  systems needs to be changed or needs to be integrated. 

9. Log decisions

Create an overview of architectural principles, design constraint and other decisions so you don’t have to redo all discussions over and over again.

10. Visualize 

Create a visualisation about how the solution should work this will help in discussion and understanding. Examples of methods to be used for visualisation are:

  • Use case diagrams –> perfect for visualising functionality with stakeholders and integrations
  • Activity or BPMN diagrams –> perfect for visualising flow on a business level or within a system.
  • Sequence diagrams, –>which are perfect for visualising integration between components.
Usecases & user stories
BPMN2.0 Userstories
sequencediagram&userstories

3 step approach for creating Perfect User Stories 

Creating a perfect User Story at once is not Agile and can be even a waste of time. Therefore Virtual BA uses a 3 step method to create Perfect User Stories:

 

Step 1: Identify User Stories and place them on the backlog with a short name, User Story Syntax(As I user X etc), a little bit of business context, the original requestor or source

Step 2: Detail. Have a session with the original requestor and add details to the business context, create acceptance criteria and define the succesfactors

Step 3: Determine Impact. Identify the impact and dependencies of the user story in relation to systems, components etc.

Need Help?

Ask Virtual BA

More on Agile Business Analyses

User stories vs Requirements

User stories vs Requirements

User stories dat klinkt best soft, misschien zelfs wel een beetje zweverig voor iets waarmee u uw project definieert. U heeft vast ook liever harde requirements. Toch verliezen de harde requirements het tegenwoordig van de softe user stories. En dat lijkt wel een...

Opgedroogde Backlog

Opgedroogde Backlog

De SCRUM purist zal nu zeggen als de backlog leeg is dan is het project klaar. Mission Accomplished. Iedereen mag naar huis en op naar het volgende project. In de werkelijkheid zal een backlog nooit echt leeg zijn, er zullen altijd wel "dingetjes" zijn die opgelost...

Zorgeloos op vakantie

Zorgeloos op vakantie

  U kent dat vast wel zo begin juni/juli raakt iedereen in de vakantie modus, in gedachten of in real life verdwijnen collega's naar verre oorden. Sommige doen dat net voor de schoolvakanties maar de meeste gaan er midden in.  Vaak...