In the previous activity, you started with three questions:
A user story puts those ideas into a short, consistent statement.
A common format is:
As a [type of user], I want [goal], so that [reason or benefit].
For the soccer availability problem:
As a coach, I want to see which players are available for an upcoming match so that I can prepare the lineup.
This sentence is short, but it answers three important questions.
Who?
The coach.
What?
See which players are available.
Why?
To prepare the lineup.
A good user story keeps attention on the user's outcome instead of immediately describing buttons, screens, or programming details.
Compare these two statements.
As a coach, I want a blue Availability button so that I can click it.
As a coach, I want to see which players are available for an upcoming match so that I can prepare the lineup.
The first statement is mostly about an interface choice. It assumes that a blue button is already the right solution.
The second describes what the coach actually needs.
Later, a designer might decide that a button is useful. But the user story should leave room for a solution that best meets the need.
When writing a user story, try to describe the outcome, not the implementation.
Even a well-written user story can still be interpreted in different ways.
Consider:
As a coach, I want to see which players are available for an upcoming match so that I can prepare the lineup.
What would count as success?
Would the coach need to see:
Some of those details may matter. Others clearly do not.
To define what successful completion means, we use acceptance criteria.
Acceptance criteria are observable conditions that help determine whether the user story has been satisfied.
For the soccer story, introductory criteria might be:
Notice what the criteria do not say.
They do not require:
They describe results that can be observed and checked.
A criterion such as:
The system should be easy to use.
may be a worthwhile goal, but it is difficult to evaluate as written.
Different people could disagree about what “easy” means.
Compare it with:
The coach can identify the match and see player availability without opening an unrelated part of the system.
The second statement gives you something more concrete to observe.
When reviewing acceptance criteria, ask:
Could two people look at the result and reasonably determine whether this condition was met?
If the answer is no, the criterion probably needs to become clearer.
Acceptance criteria should support the user story, not introduce unrelated requirements.
Return to the story:
As a coach, I want to see which players are available for an upcoming match so that I can prepare the lineup.
Now consider this proposed criterion:
The system displays each player's favorite professional soccer team.
That information could be interesting.
It does not help determine who is available for the match.
Because it does not support the current story, it does not belong in the acceptance criteria for this work.
Technical requirements stay manageable when every condition has a reason to be there.
A soccer program might eventually need many user stories:
You do not need to solve all of those needs at once.
A useful user story creates a focused piece of work that can be understood and checked.
That focus is especially important in technical work. Smaller, meaningful goals are easier to build, test, discuss, and revise.
A user story describes a user's need:
As a [user], I want [goal], so that [reason].
Acceptance criteria define the observable conditions that must be true for that story to be considered successful.
Together they turn a vague idea into a focused result that technical work can be organized around.
The next activity shows how that focused result becomes smaller tasks and how those tasks are checked.