# Backlog, User Stories and Definition of Done ### Overview The backlog is the living plan for delivery. It turns outcomes, user needs, technical work, security tasks, defects and operational improvements into visible, prioritised work. ### Backlog Content A healthy backlog may include: * user stories * research tasks * design tasks * technical tasks * integration tasks * security tasks * data tasks * testing tasks * documentation tasks * support tasks * defects * technical debt items * assurance tasks * supplier tasks ### User Story Format A user story should normally describe the user, the need and the value. Example: ```markdown As a [type of user] I need [capability or outcome] So that [benefit or reason] ``` ### Good User Stories Good user stories are: * grounded in user need * small enough to deliver * clear enough to estimate * testable * linked to acceptance criteria * free from unnecessary solution bias * prioritised * owned ### Acceptance Criteria Acceptance criteria define what must be true for the work to be accepted. Good acceptance criteria are: * objective * testable * specific * understandable * linked to the story or deliverable * capable of evidence Example: ```markdown Given an authorised user is viewing the case dashboard When they filter by status Then the dashboard only displays cases matching the selected status And the filter state is clearly visible And the result count is updated ``` ### Definition of Ready A backlog item is ready when: * the objective is clear * the user or stakeholder need is understood * acceptance criteria are drafted * dependencies are known * required inputs are available or planned * security or data implications are identified * the team can estimate the work * the item is small enough for the planned iteration ### Definition of Done A backlog item is done when: * acceptance criteria are met * code or artefacts are reviewed where applicable * tests are complete * security considerations are addressed * documentation is updated * evidence is stored * stakeholders have reviewed where required * no critical defects remain * the item is marked complete in the backlog ### Backlog Hygiene The backlog should be reviewed regularly to remove: * duplicate items * stale items * unclear items * items outside the Statement of Work * items with no owner * items with no visible value ### Backlog and Scope Control Not every backlog item is automatically in scope. The Statement of Work defines the authorised scope. The backlog explains how that scope is delivered. Where a new backlog item materially changes scope, cost, timeline, risk, acceptance or IP position, it must be assessed through change control. ### Traceability Where appropriate, backlog items should trace to: * outcome * user need * deliverable * milestone * acceptance criterion * risk * decision * release --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://framework.aic.io/agile-delivery-playbook/delivery-system/backlog-user-stories-and-definition-of-done.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.