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.
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
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.
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
De 5 meest voorkomende soorten automatisering
Automatisering kan veel verschillende vormen aannemen, misschien is dat ook wel de reden dat er zo veel automatiseringsprojecten mislukken. Simpelweg omdat men elkaar niet begrijpt of omdat men denkt het over hetzelfde te hebben. Vaak gaat het over het automatiseren...
Het ideale SCRUM Team
Het ideale SCRUM Team SCRUM is hot, maar of het nu een zegen of een vloek is, daar zijn de meningen over verdeeld. Een van de belangrijkste key succesfactoren is het SCRUM Team. De inrichting van het team bepaalt het succes van het project. Immers in SCRUM bepaalt het...
Een Digitaliseringsstrategie in 3 stappen
Stap 1: Ontwikkel een digitaliseringsvisie Stap 2: Bepaal de digitale oplossingsrichting Stap 3: Bepaal de benodigdhedenStap 1: Ontwikkel een digitaliseringsvisieDe eerste stap voor een digitaliseringsstrategie is bepalen wat u wil bereiken en waarom. Niet in termen...
4 stappen van een goede business analyse
Of u nu uw Customer Experience wil verhogen, uw efficiëntie wil verbeteren of nieuwe producten wil introduceren. Één ding is zeker er is verandering nodig. Om te weten wat u moet veranderen zal u uw business moeten analyseren. Niet alleen om te bepalen wat er in uw...
Nieuw SCRUM Backlog Generator
Druk? Veel wensen van verschillende gebruikers maar eigenlijk geen tijd om het allemaal netjes te verwerken in goede User Stories? Maak dan gebruik van de Virtual BA – SCRUM Backlog Generator De SCRUM Backlog Generator van Virtual BA vertaalt losse emails, word...
Hoe herken je een goede business analist
Een Business Analist zorgt er voor dat wensen van de business vertaalt kunnen worden naar IT oplossingen. Dit doet de Business Analist door enerzijds goed te luisteren naar wat de Business (afdelingen) willen bereiken en dit zo te formuleren dat de Technische...
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...
Automatiseren, Digitaliseren of Robotiseren?
Automatiseren, Digitaliseren en Robotiseren drie termen in de IT, die over het zelfde lijken te gaan. Vaak worden deze termen door elkaar heen gebruikt terwijl ze toch verschillende dingen betekenen. In deze blogpost duid ik de verschillende betekenissen. Wat is...
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
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...