User stories explained — the As a / I want / so that format, INVEST, acceptance criteria — and iteration planning, often called sprint planning, with velocity in East Agile Tracker.
A user story is a short description of something a user needs, written from their point of view. Iteration planning is how a team decides which stories it will work on in the next time box. Many teams call this time box a sprint and the meeting sprint planning; East Agile Tracker calls them iterations and iteration planning.
What a user story is
Section titled “What a user story is”The common template is:
As a [kind of user], I want [some capability], so that [some benefit].
For example: As a project manager, I want to see which stories are blocked, so that I can clear them before the iteration ends.
The template names who benefits, what they need, and why. The “why” lets the team find a simpler way to deliver the same benefit. A story is a placeholder for a conversation, not a full specification: the details are worked out between the people asking and the people building.
INVEST: is the story ready?
Section titled “INVEST: is the story ready?”INVEST is a checklist for a well-formed story:
- Independent — can be built and delivered on its own.
- Negotiable — the details are open to discussion.
- Valuable — delivers something a user or customer cares about.
- Estimable — the team understands it well enough to size it.
- Small — fits comfortably within one iteration.
- Testable — there is a clear way to tell that it is done.
Acceptance criteria
Section titled “Acceptance criteria”Acceptance criteria state what must be true for the story to count as done. Writing them in Given / When / Then form makes each one an acceptance test:
Given a story with an unresolved blocker, when I open the Blocked column, then the story is listed there.
Criteria are agreed before work starts, so the team and the person who accepts the story share the same definition of done.
Iteration planning
Section titled “Iteration planning”Iteration planning answers one question: what will we work on in this iteration? It needs three inputs:
- An ordered backlog — stories ranked by priority, with the top ones ready (meeting INVEST, with acceptance criteria).
- Estimates — each candidate story sized in story points.
- Velocity — how many points the team completes per iteration. See What is velocity?.
The team takes stories from the top of the backlog until the total reaches its velocity. Taking on more than that relies on the team suddenly working faster; taking on less leaves capacity unused.
How East Agile Tracker does it
Section titled “How East Agile Tracker does it”- Stories come in four types: features, bugs, chores, and releases. Only features take points by default. See Stories.
- Acceptance criteria go in the description. There is no separate field; the criteria belong in the description before the story is started. When a story is delivered, the product owner accepts or rejects it against those criteria. See the state machine and the acceptance loop.
- The backlog is one strictly ordered list, and it projects the upcoming iterations from velocity, three or four ahead, marking any group that exceeds velocity. See Iterations.
- Iteration planning is largely automatic. With auto-plan iterations on (the default), the current iteration fills to your velocity; pulling in a new story moves the lowest-priority one back to the top of the Backlog. Teams that commit to a fixed scope, Scrum-style, can turn auto-plan off and plan as much as they like, with a counter that turns red above velocity. See Planning an iteration.
- Creating a story opens a composer for the title, description, type, estimate, and owners. See Create a story.
Further reading
Section titled “Further reading”- What are story points? — sizing stories.
- What is velocity? — the capacity side of planning.
- eXtreme Programming — where user stories and the planning game come from.