Product Owners, business analysts and product teams · 2 days (14 hours) · in-house, 10 participants maximum · Bordeaux or remote
Backlog and user stories: writing what the team can actually ship
At a glance
- Duration
- 2 jours (14 heures)
- Format
- On site and remote
- Group size
- 10 participants maximum
- Level
- Beginner
- Audience
- Newly appointed Product Owners, handed the role without the training
- Prerequisites
- No prior knowledge of agile methods: the vocabulary needed is covered at the start of the session.
- Methods
- One third input, two thirds workshop: the theory adds up to half a day across the two days.
- Assessment
- Before the session: an online positioning questionnaire (15 minutes) and three to five real backlog items sent in by each participant, which become the raw material for the workshops.
- Lead time
- Scheduled during framing, to suit your availability
- Pricing
- On a quote basis, depending on format, duration and number of participants. The first call is free.
- Accessibility and disability
- See the dedicated section
Everyone knows the "as a… I want… so that…" template. And yet most of the backlogs I take over on assignment are full of unusable lines: a generic role, a benefit that merely restates the action, no acceptance criteria, and a team left guessing. These two days are not about the template, they are about what goes in it. Participants work on their own backlog, the one they will reopen the following Monday, and leave with a refined, sliced and prioritised chunk of it, ready to enter a sprint.
Learning objectives
- Tell the real need apart from the solution the requester has already decided on
- Write a user story that answers the three questions: for whom, what, and above all why
- Write verifiable acceptance criteria that convert straight into test cases
- Review a story against the INVEST grid and decide, criterion by criterion, whether to keep or rewrite it
- Slice an oversized story into shippable increments without losing user value
- Prioritise a backlog with MoSCoW and RICE, and justify a refusal to the requester
- Run a refinement session that produces a batch of dev-ready stories
Programme
01What a backlog is for, and why yours no longer does that
Day 1 · 1 h 30- Project versus product: a project ends and is measured by compliant delivery, a product evolves as long as it has users and is measured by the value it creates
- What a backlog has to let you decide, and what it is not: neither a dumping ground for requests nor a set of meeting notes
- The trap of a Product Owner who cannot say no: without the power to arbitrate, the role degrades into backlog secretarial work
- Live diagnosis: each participant opens their backlog and counts the lines a team could build without asking a single question
02Writing a story that surfaces the real need
Day 1 · 2 h- The "as a [role], I want [action], so that [benefit]" template: its only merit is forcing three answers — for whom, what, and above all why
- The before/after example, discussed as a group: "add an export button" versus a story that names the role, the expected format and what happens downstream
- How a good story reveals that the real need sits somewhere other than the requested solution
- The four recurring mistakes: a technical task dressed up as user value, a "so that" that restates the action, the sprawling story, the generic "as a user" role
- Workshop: rewriting three items from each participant's backlog, followed by peer review
03Acceptance criteria, the part everyone skips
Day 1 · 2 h- Why a story without acceptance criteria is not ready to build: they, not the estimate, are what defines "done"
- Writing a precise, verifiable, testable criterion: data scope, expected format, edge case, behaviour when there is no result at all, performance requirement
- From criterion to test case: a well-written criterion becomes a scenario a tester who attended none of the workshops can execute
- How many criteria is right: when you find yourself writing fifteen, it is usually the story that needs slicing
- Workshop: producing a full set of criteria for two stories rewritten in the previous module, reviewed by a partner playing the tester
04Reviewing with INVEST
Day 1 · 1 h 30- The INVEST grid as a review tool, not a dogma: independent, negotiable, valuable, estimable, small enough, testable
- What each criterion actually detects in a real backlog, and which one fails most often
- The decision rule: two failed criteria or more and the story is rewritten before it enters a sprint
- Assessed workshop: six stories to grade, correct and justify, with group debrief
05Slicing without losing the value
Day 2 · 2 h- Spotting an oversized story: it contains "and", "or", three screens, or the team cannot estimate it without guessing
- Slicing axes that work on a business backlog: by journey step, by business rule, by data type, by user variant, by happy path then edge cases
- The slice to avoid: by technical layer, which produces increments no user can verify
- Checking after slicing that every increment remains shippable and demonstrable on its own
- Workshop: slicing the largest story each participant brought, then proving to the group that the first slice stands on its own value
06Prioritising, and owning the refusals
Day 2 · 2 h- Why prioritisation that refuses nothing is not prioritisation: if everything is a priority, the team arbitrates in your place, silently
- MoSCoW: setting must, should, could and won't over a dated scope, and holding the won't column
- RICE: reach, impact, confidence, effort — what the score objectifies and what it does not replace
- Phrasing a refusal to a requester: name the trade-off, the counterpart, and the condition for revisiting it
- Workshop: group prioritisation of the participants' consolidated backlog, then a role play refusing a request argued by the trainer
07Refinement as a ritual, not a chore
Day 2 · 1 h 30- Placing refinement in the team cadence: frequency, duration, attendees, material to prepare beforehand
- What a refinement session must produce: a batch of stories the team agrees to plan without reservation
- The conditions for a story to enter sprint planning: explicit benefit, written criteria, workable size, identified dependencies
- Holding backlog quality over time: what to do with the old lines nobody ever reopens
- Workshop: building your team's refinement template, with agenda and expected output
08Final role play and thirty-day application plan
Day 2 · 1 h 30- Assessed role play: produce a backlog slice of three to five refined stories, criteria included, and defend it before the group acting as the development team
- Knowledge validation quiz, corrected and discussed
- Individual application plan: what each participant changes in their backlog the following week, in three dated actions
- Framing the remote follow-up call and the topics to bring to it
Who it is for
- Newly appointed Product Owners, handed the role without the training
- Business analysts moving into a product role
- Product teams in startups and SMEs where several people write the stories
- Project managers who inherit an existing backlog and have to put it back in order
- Developers and testers on the receiving end who want a say in story quality
What participants take away
- A user story template and an acceptance criteria template, in your tracking tool's format
- The INVEST grid as a review checklist, usable alone in three minutes per story
- The catalogue of slicing axes covered in session, each with a worked example
- A MoSCoW grid and a RICE spreadsheet pre-filled with your own criteria
- A refinement session template: agenda, duration, roles, expected output
- The backlog slice produced over the two days, directly reusable in a sprint
- The before/after examples built from your own items, kept by the company
- An individual application plan in three dated actions
Prerequisites
- No prior knowledge of agile methods: the vocabulary needed is covered at the start of the session.
- Working with a development team, or about to.
- Bring a real backlog, or failing that a list of pending requests: the workshops run on your own items. A worked-through sample backlog is provided for participants who do not have one yet.
- A laptop with access to your tracking tool (Jira, Azure DevOps, Notion, Trello, or a plain spreadsheet).
Teaching methods
- One third input, two thirds workshop: the theory adds up to half a day across the two days.
- Work on the company's real backlog, brought by the participants and anonymised where needed.
- Before/after examples discussed as a group, drawn from assignment backlogs and made anonymous.
- Systematic peer review in pairs: you write, then someone who was not inside your head tests what you wrote.
- Role plays: the tester receiving the story, the requester on the wrong end of a refusal.
- A complete sample backlog for participants whose own items cannot be used in session.
- Group debrief and written decisions at the end of every workshop.
Assessment of learning
- Before the session: an online positioning questionnaire (15 minutes) and three to five real backlog items sent in by each participant, which become the raw material for the workshops.
- During the session: every workshop produces a written deliverable, reviewed in pairs then discussed as a group — rewritten story, set of acceptance criteria, slicing, prioritised backlog.
- End of day 1: assessed review exercise — six stories to grade against the INVEST grid, correct and justify, with group debrief.
- End of session: final role play assessed against a grid handed out at the opening — produce a backlog slice of three to five refined stories, acceptance criteria included, and defend it for ten minutes before the group.
- A twenty-question validation quiz (template, criteria, INVEST, slicing, prioritisation), corrected and discussed before closing.
- Four to six weeks later: a 45-minute remote follow-up to measure what has actually been applied to the backlog and clear the blockers met in real conditions.
Where what I teach comes from
Adrien Bouthet, freelance IT Project Manager and Product Owner based in Bordeaux, independent since March 2019. What I teach over these two days comes from backlogs I hold on assignment, not from an off-the-shelf deck. Since February 2025 I have been designing and grooming the Jira backlog for La Banque Postale's onboarding journeys — account opening, adult and minor journeys, Livret A subscription — with business, technical and partner teams, on a project budget in the order of one million euros and under KYC and GDPR constraints. That is the kind of context where you learn what an acceptance criterion is worth: it turns into a test scenario, and the journey either goes to production or does not. As Product Owner at Ctrl Up in 2023 I led development in Scrum and supported developers on the client's own premises. At EDF, between 2020 and 2022, I steered a portfolio of IT and industrial IoT projects including a demand management application absorbing around 20,000 tickets a year, with teams of 2 to 10 people. I have also been teaching at Bordeaux schools since 2020 (EPSI, Ynov, WIS, Infosup, Nexa), and the session material reuses the before/after example, the testable acceptance criteria and the INVEST grid I publish on this site.
Real example
Something concrete: on La Banque Postale's onboarding journeys, designing and grooming the Jira backlog with business, technical and partner teams supported the integration of 2 external partnerships and a production held to fewer than 3 incidents per year. Acceptance criteria there become the test scenarios directly: that is the standard the session's workshops reproduce, on your own items.
Read the case studyFrequently asked questions
Two days for user stories, isn't that a lot?+
The template itself takes ten minutes to explain, which is precisely why half-day sessions on the subject change nothing. Day 1 goes into what actually makes the difference: finding the real need and writing testable acceptance criteria. Day 2 covers slicing, prioritisation and refinement, in other words holding the backlog over time. Two thirds of the time is workshop work on your own items, not lectures.
Our stories are written by the business and the developers, not by a Product Owner. Is it still worth it?+
Yes, and the in-house format is designed for exactly that. When several people write, the issue is not individual skill but the shared convention: which questions you ask before writing, what you call "done", who decides when two requests contradict each other. Mixing business, product and development in the same room is often the real benefit, because the convention gets agreed there and then.
Do we need to use Jira?+
No. The content is tool-agnostic: Jira, Azure DevOps, Notion, Trello or a spreadsheet, we work in yours. The templates handed over are adapted to your ticket format during the session so they are usable as-is the following Monday.
Do we need to be running Scrum?+
No. A useful backlog, testable acceptance criteria and owned prioritisation are worth as much in continuous flow or Kanban as in sprints. The refinement and planning-entry modules are adapted to whatever cadence you actually run.
How is this different from the Agile and project management training?+
The Agile and project management training covers the whole frame: ceremonies, dashboards, steering by objectives, for leaders and teams getting started. This session goes one level down and stays on a single object, the backlog and what gets written in it. They complement each other rather than replace each other: you can take this one without having taken the other.
Our backlog is confidential. How does that work?+
The workshops run on your premises or in your environment, on your own tools, and nothing is extracted from your information system. Items sent in beforehand can be anonymised by your team, and a confidentiality agreement is signed before the session if your internal policy requires one.
How many participants at most?+
Ten. Beyond that, peer review and the final role play no longer fit the time available and the session drifts back into a lecture. For a larger headcount we run two sessions rather than one big group.
Can the session run remotely?+
Yes, over video, with the same flow and the same workshops in breakout groups. On-site is still preferable for day 2, where prioritisation and the refusal role plays benefit from everyone being in the same room. The mixed format is common: day 1 remote, day 2 on-site in Bordeaux or at your offices.
Framework and terms
Funding
These sessions are invoiced directly to the company, out of its own skills development budget. They are not eligible for pooled funding schemes (OPCO, CPF, France Travail), which require Qualiopi certification.
Certification
This session is not a certifying course. I do not deliver any Scrum.org, Scrum Alliance, Scaled Agile (SAFe) or PeopleCert (ITIL) certification, nor any qualification registered with the RNCP or the Répertoire spécifique. The goal is operational: practices you can apply, not a diploma.
Contractual framework
Each session is covered by a professional training agreement (convention de formation professionnelle) signed before the start, setting out the objectives, the programme, the duration, the delivery arrangements and the agreed fee. The internal rules applicable to the session are handed to participants at the opening.
Certificate of attendance
A certificate of completion is handed to each participant at the end of the session. It states the objectives, the nature and the duration of the training, along with the results of the assessment of learning.
Accessibility and disability
Disability referent: Adrien Bouthet, contact@adrienbouthet.fr. Any situation requiring an adjustment (access to the premises, adaptation of the materials, of the pace or of the assessment arrangements) is examined during the framing phase, within 5 working days. If the adjustment exceeds our means, we refer to specialised resources (Agefiph, Cap emploi).
A backlog to put back in order
Book a free first call. We look at the real state of your backlog, the number of participants and your scheduling constraints, and I propose a flow built on your own items.
The matching service
Freelance Product Owner