3.1 User Stories, Agile Estimation, and the Definitions of Ready and Done
Key Takeaways
- A user story expresses a requirement from the user's perspective: as a [role], I want [capability], so that [benefit].
- Agile estimation is relative, not absolute — story points and t-shirt sizing compare items to each other rather than predicting hours.
- The Definition of Ready states the conditions an item must satisfy before a team will pull it into an iteration.
- The Definition of Done states the conditions a product increment must satisfy before it can be called complete, and it applies to every item.
- Personas are a technique for identifying the specific benefits a solution can deliver to its users.
3.1 User Stories, Agile Estimation, and the Definitions of Ready and Done
Quick summary: A user story captures a requirement from the user's point of view. Agile estimation — story points and t-shirt sizing — sizes work relatively, not in hours. The Definition of Ready is the entry gate into an iteration; the Definition of Done is the exit gate out of it. Personas identify the specific benefits a solution delivers to its users.
User stories
A user story is a short statement of a requirement written from the user's perspective, in the conventional form:
As a [role], I want [capability], so that [benefit].
For example: As a warehouse supervisor, I want to see stock levels updated in real time, so that I stop ordering items we already hold.
Three parts, three jobs. The role identifies who benefits, which forces you to know who the users actually are. The capability states what the system must let them do — deliberately without specifying how. The benefit states why it is worth building, which is what allows a product owner to prioritize honestly and a project board to test continued business justification.
Stories are not specifications. They are, in the standard phrase, a placeholder for a conversation. The detail is agreed between the team and the product owner close to the point of building, when it is cheapest to be precise.
Attached to a story are its acceptance criteria — the specific, testable conditions that must be true for that story to be accepted. Acceptance criteria are story-specific; they differ from the Definition of Done, which applies to everything.
An epic user story is one that is too large to deliver in a single iteration and will be decomposed as it rises up the backlog.
Personas
A persona is a documented, named archetype of a user group: their goals, their context, their constraints, what frustrates them. Personas are the technique used to identify the specific benefits a solution can deliver to its users, and they feed directly into the project canvas workshop where user groups are defined and prioritized.
Personas do work that abstract role names cannot. "As a user, I want…" tells you nothing about priority. "As Priya, a part-time night-shift supervisor who cannot leave the floor to use a desktop" tells you the capability has to work on a handheld device, and tells you what benefit to measure.
Agile estimation
The defining feature of agile estimation is that it is relative. Rather than trying to predict how many hours a task will take — something humans do badly and consistently optimistically — teams compare items to each other. Relative judgement is far more reliable than absolute judgement.
The syllabus names two techniques:
Story points
An abstract unit of size that blends effort, complexity and uncertainty into one number. Teams typically use a modified Fibonacci-style progression (1, 2, 3, 5, 8, 13, …) so that the gaps widen as items get larger, reflecting the fact that big things cannot be sized precisely.
Story points are meaningful only within one team. A five-point story in one team is not comparable to a five-point story in another, and comparing velocities between teams is a well-known management error that pushes teams to inflate estimates.
Once a team has a few iterations of history, its velocity — points completed per iteration — supports forecasting: a 120-point release with a velocity of 20 will take roughly six iterations.
T-shirt sizing
An even coarser scale — XS, S, M, L, XL — used when precision is neither achievable nor needed. It is quick, it is accessible to non-technical stakeholders, and it is well suited to sizing a project backlog early, when items are still epics. Teams often size in t-shirts at project level and convert to story points as items approach an iteration.
Planning poker is a common way of running either technique: each team member privately picks an estimate, all reveal at once, and the outliers explain their reasoning. The value is the conversation the divergence provokes, not the number that results.
Definition of Ready
The Definition of Ready (DoR) is the team's agreed set of conditions that a backlog item must satisfy before the team will commit to it in an iteration. It is an entry gate.
A typical Definition of Ready requires that an item is:
- Small enough to be completed within one iteration
- Written with clear, testable acceptance criteria
- Understood by the whole team, with dependencies identified
- Free of blocking external dependencies, or with those dependencies scheduled
- Estimated by the team
The purpose is to prevent the most common cause of failed iterations: pulling in work that turns out to be underspecified, and discovering it on day four.
Definition of Done
The Definition of Done (DoD) is the team's agreed set of conditions that must be satisfied before a product increment can be called complete. It is the exit gate, and it applies to every item rather than being written per story.
A typical Definition of Done requires that the work is:
- Built and integrated into the main branch
- Covered by automated tests, all passing
- Peer reviewed
- Compliant with security, accessibility and regulatory standards
- Documented to the agreed level
- Demonstrated and accepted by the product owner
- Deployable to production
The Definition of Done is the mechanism by which quality is protected in an agile project. Because time and cost are constrained and scope flexes, the pressure at the end of an iteration is always to declare something finished that is not. A published, non-negotiable Definition of Done is what makes "we will drop a story" the available response instead of "we will skip the testing".
Ready versus Done — the distinction that gets tested
| Definition of Ready | Definition of Done | |
|---|---|---|
| Gate | Entry — before work starts | Exit — before work is accepted |
| Applies to | Backlog items about to be pulled in | Every completed increment |
| Question it answers | "Do we understand this well enough to start?" | "Is this genuinely finished?" |
| Failure if absent | Iterations stall on underspecified work | Technical debt accumulates and quality collapses |
Technical debt
The eventual consequence of poor system design or poor software development is technical debt — the accumulated cost of shortcuts that will have to be repaid, with interest, in slower future delivery. A weak or unenforced Definition of Done is one of the principal ways technical debt is created, which is why the two ideas belong together.
Putting it together in one flow
- A requirement enters the project backlog as an epic, sized in t-shirts.
- The product owner and team refine it into user stories with acceptance criteria, guided by personas.
- Stories are estimated in story points by the team.
- A story that meets the Definition of Ready becomes eligible for an iteration.
- The team builds it; it is complete only when it meets its acceptance criteria and the Definition of Done.
- Completed points feed velocity, which updates the release map forecast.
What technique is used to help identify the specific benefits a solution can deliver to its users?
Which statement about the Definition of Done is correct?
Why does agile estimation use relative units such as story points rather than hours?