A familiar situation: you approach an IT company asking them to estimate the cost of development, and in return you get excuses along the lines of "send us a proper spec and then we'll do the maths". Or a veiled offer to first pay generously for a detailed specification to be drawn up, and only then, on its basis, to get a cost estimate. Nobody has worked that way for a long time.
Why "a proper spec" is an answer about nothing
And yet no one can really explain what that "proper" spec actually is. More importantly, no one guarantees that once the document is finally written, the cost of development will still be acceptable to you. It turns out to be a strange bargain — you pay for a text that will only later reveal whether the project itself is within your means.
The conversation about money needs a different entry point: one where the estimate and the documentation appear at the same time, rather than one after the other.
Once the method of presenting business-level requirements through user stories was described, everything else became hopelessly outdated.ANIART
What a user story is
A user story is a short statement of intent that describes something the system should do for the user.
- A user story is not a detailed description of requirements — that is, it contains no detailed description of the interface or of responses to an action. It is a negotiable expression of intent.
- It is short and easy to read — clear to developers, stakeholders and users alike.
- Most importantly: every user story lends itself easily to estimation, so the effort needed to implement it can be determined quickly.
What an ideal story looks like
Your ideal user story should look like this:
As a <user ROLE>, I <ACTION>, <VALUE>.
Three blocks are then added to that statement:
- Acceptance criteria.
- Error handling.
- Technical notes.
Role
These are users or groups of users. For example, your system may not have very many of them — User, Guest, Operator and Administrator.
Action
This is the essence of the story, "what needs to be done". What can be improved. There should be a single action — the main one. There is no sense in describing "logs in and performs a search" or "enters search parameters and performs a search". State the action you genuinely need.
It is important to describe the story at the level of "WHAT?" is being done, not "HOW?". That is the heart of a story. Describe the problem, not its solution.
Value
Your story must have value — a result, and it must affect someone. That impact ultimately leads to a goal that is valuable to you. The notion of value can be replaced by that of impact.
Examples from real projects
Below are examples of what user stories look like, taken from real projects.
What you get once the stories are ready
By preparing a user story, you have articulated the business value for the end user. But the charm of a user story is also that it formulates not only business value, but the requirements for development and testing as well.
In other words, that same set of stories serves as excellent business-level documentation — a quick way to understand exactly what your system does.
Estimation
Every story lends itself to estimation, so the implementation effort is determined quickly — without weeks of preliminary description.
Documentation
Finished stories are business-level documentation: they show what the system does without diving into interfaces.
Development requirements
A statement of intent with acceptance criteria goes straight into the development team's work.
A basis for testing
Acceptance criteria give you something to check the story against — tests are written before the code.
Tips for writing user stories
- It is better to write many smaller stories than a few bulky ones.
- Ideally, each story should be written without technical jargon.
- Stories should be written so that they can be tested. Tests should be written before the code.
- Avoid the UI for as long as possible: a story should work without being tied to specific elements.
- Every story should carry an estimate.
- A story must have an end value — that is, it must lead to a concrete result or produce an impact.
- A story must fit within an iteration.
INVEST: quality criteria for a user story
The Scrum guide offers six criteria for checking the quality of a story. Here they are — along with how we read each of them in our work.
| Criterion | Scrum guide | ANIART |
|---|---|---|
| Independent | Reduced dependencies = easier to plan | Independent. Interdependencies with other stories are kept to a minimum. The story is easy to isolate and implement. |
| Negotiable | Details added via collaboration | Negotiable. The description is sufficient for everyone involved to understand it: after reading it, everyone is ready to contribute additions. |
| Valuable | Valuable | Carries clear value. |
| Estimable | Too big or too vague = not estimable | Suitable for estimation. Stories that are too large or vaguely worded are hard to estimate with any precision. |
| Small | Can be done in less than a week by the team | Compact enough to be completed in less than a week with the whole team working on it. |
| Testable | Good acceptance criteria | Testable. Acceptance criteria are sufficient to check the story against them. |
How this works in practice
- We state the intent. For each role — User, Guest, Operator, Administrator — we write down one main action and the value it leads to.
- We add acceptance criteria. For each story — the conditions it will be checked against, plus error handling and technical notes.
- We check it against INVEST. A story that fails on "Small" or "Estimable" is broken down into smaller ones.
- We estimate. Every story gets an estimate — and those estimates add up to the cost of development.
