Stories ready for discussion
How do you turn a vague request into verifiable user stories without letting AI invent the business rules?
1250 € per session, excl. VAT
In short
“Turning a need into user stories” is a private in-person session of half a day for product owners and product managers preparing a backlog or business analysts and project managers working with a development team. Groups of up to 12 participants, in French, with exercises on your own work cases.
Why this training?
A request such as ‘allow an appointment to be changed’ is not enough to guide development. It conceals actors, constraints and exceptions that can easily lead to disagreements during acceptance testing. AI can suggest wording and identify ambiguities, but it can also invent plausible rules. The training teaches participants to separate facts, assumptions and questions, then check each story against the documented need. Running case study: The fictitious organisation Melvane Réparation wants to allow its customers to reschedule an appointment through their personal account area. The initial request combines customer autonomy, technician availability and fewer phone calls. The permitted time limits and exceptions still need clarification. Transfer to the workplace: In the following week, revisit an anonymised need, produce three stories and have them reviewed by a business representative and a developer. Compare the shortcomings identified before and after correction using the assessment grid used during the session.
Objectives of this training
- Extract actors, intentions and constraints from an initial request
- Distinguish confirmed rules, assumptions and missing information
- Break down a need into stories that deliver identifiable user value
- Write observable acceptance criteria with the help of AI
- Assess and correct a backlog using an explicit assessment grid
Who is it for and what are the prerequisites?
Roles and tasks concerned
- Product owners and product managers preparing a backlog
- Business analysts and project managers working with a development team
Prior skills
- Have previously formulated and refined a request in a generative AI assistant
- Understand the concepts of a backlog, a user need and functional acceptance testing
What you will work on
Clarify before generating
Objective: Turn the initial request into an explicit need. Actors, problem, expected outcome, scope and constraints. AI prompt distinguishing sourced facts, assumptions and questions; data protection.
Break down by user value
Objective: Obtain stories that can be discussed independently. Differences between an epic, a story and a task; actor–capability–benefit wording; vertical slicing and dependencies.
Make expectations testable
Objective: Describe the behaviours that allow a story to be accepted. Acceptance criteria, Given–When–Then scenarios, edge cases; distinction from shared quality requirements.
Review and measure quality
Objective: Correct the backlog before its collective review. INVEST grid: independence, negotiability, value, estimability, size and testability; limitations of automated assessment.
What you take away
- Needs brief with a register of assumptions and questions
- Backlog of five to seven user stories linked to the need
- Detailed acceptance criteria for three stories
- Completed quality assessment grid with corrections and points to validate
Method and assessment
- Short explanations followed by immediate practice on the running case study.
- Individual work followed by work in pairs, with cross-review of the outputs.
- Facilitated group discussion: what works, what needs correcting and what remains a human decision.
- Preparation: Have access to a generative AI tool authorised by the organisation Prepare an anonymised functional request; a fictitious case file is provided for the exercises
Observable criteria: Each story specifies an actor, an expected capability and identifiable value; Each rule used refers to the case file or is marked ‘to be confirmed’; The breakdown preserves user value without being limited to technical layers; The three detailed stories include an observable standard scenario and exception; The grid shows the number of compliant stories per criterion before and after correction.
Frequently asked questions
Do you need to know how to code?
No. You need to be able to explain a user need and discuss expected behaviours.
Can you use a real need?
Yes, but only if anonymised and used in an authorised tool, without personal data or confidential information.
Does AI decide on business rules?
No. It suggests questions; stakeholders confirm the rules and decide on exceptions.
Are the stories ready for development straight away?
They are prepared for review. Their maturity depends on business validation, dependencies and collective estimation.
Last updated: