User stories
One user story is one small thing a person can do, checked and working.
Like "an admin can export the current report as CSV". Each story costs $5 when its pull request meets the acceptance criteria you approved.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
Small enough to test.
- 2
Counted before you approve.
- 3
$5 each, when completed.
- 4
Edge cases can be their own story.
How requests turn into a count.
These are samples. Your real count comes from your own PRD, which you approve before anything starts.
- 1
Fix the empty state on team invites: 1 story, $5
One screen and one job. The story is the empty state and its copy.
- 2
Add CSV export to the reports page: 4 stories, $20
Export the current report, keep the filters, handle large reports, and show a clear error on failure.
- 3
Let admins bulk-deactivate users: 6 stories, $30
The action itself plus edge cases such as the last admin and people with open sessions.
How to tell one when you see it.
Use this when you read your first PRD.
- It names who is doing the thing.
- It does one thing, not three.
- A person can check it by clicking.
- Its criteria leave nothing to opinion.
Your big request becomes a list of small pieces that each finish on their own
- Think about the last feature you wanted badly. It probably started as one sentence, something like: customers should be able to pay us in a second currency. That sentence is easy to say. It is hard to build, because it hides a dozen decisions, and nobody can tell when it is done.
- A user story fixes that. It takes one sentence and breaks it into small pieces. Each piece names a person, an action and a reason. Each piece can be checked on its own, so you can see when it is finished. Instead of waiting for a large feature to be finished in one go, you get a list of finished parts that add up to the whole.
- This changes how the work feels from your side. You stop asking when the big thing will be ready, because the answer is spread across the list. You can see which parts are done, which part is next, and which part you may want to drop. The big request stops being a fog and becomes a set of pieces you can look at.
- The same idea helps you with a request you have already written. Take one feature you asked for last quarter and read it again as a list. You will likely find two or three hidden pieces that nobody named, such as what happens when a payment fails or when a user has no email address. Those hidden pieces are where most delays come from.
- Once the request is split, we write it down in a PRD. A PRD is a plain document that lists every story, what each story must do, and how you will know it is done. You read it, change what you need, and approve it. Nothing is built until you approve it.
- The end result is a request you can read in ten minutes and understand fully. It is not a promise that everything will go perfectly. It is a shared picture of what will be built, in pieces small enough that you can see each one clearly before the work starts.
- Think of the list as a map rather than a promise. It shows the road from where you are to where you want to be, and it marks the turns. If the road changes, you redraw the map and keep going, instead of pretending the first version was right.
You know the price of each piece before anything is built
Every completed user story costs $5.
That is the whole price rule. You do not pay for hours, for seats or for a tool you may not use. You pay for each story whose pull request meets the acceptance criteria you approved in the PRD.
Because the PRD lists the stories, you can count them before you approve anything.
Count the stories, multiply by $5, and you have the cost of that request. If the total does not fit your plan, you can cut a story, combine two stories or ask us to rethink the request, all before any build begins.
The minimum is 100 user stories a month, which is $500.
That covers the smallest monthly amount you can buy. Most of the value comes from how clearly you can see what each story costs, not from the minimum itself. A short request with eight stories and a large request with eighty stories use the same rule.
This also makes budget talks easier inside your company.
A finance lead can ask what the request costs, and you can point to the list. Each line has a count and each count has a price. There is no hidden line that appears later and no surprise that shows up at the end of the month.
Prepayment is part of the same clear picture.
The full prepayment is made before work begins, and each completed story uses $5 of it. We do not bill you by the hour and then argue about the hours.
Think of it as a menu with the prices written next to each dish.
You still choose what to order. The difference is that you can add up the bill before the food arrives, and you know exactly what you are getting for each line.
The price does not depend on how long a story takes to read.
Two stories of the same kind cost the same. That keeps the conversation on what the product should do, not on how many hours a single item might take. The $5 applies to completed stories only, so the price stays tied to finished work, which is the only thing you asked for.
A clear list of stories shows you exactly what you are buying
A good story has three parts.
First, a person: who uses the feature. Second, an action: what that person does. Third, a reason: why they want it. The reason is often the part teams skip, and it is the part that decides whether the feature is useful when it lands.
Each story also has acceptance criteria.
These are the checks that say the story is done. A criterion should be something a person can check by clicking through the feature or reading the result. For example, the reset email arrives in the inbox, the link works once, and an expired link shows a clear message. If a criterion cannot be checked, we rewrite it before you approve the PRD.
Edge cases get their own stories.
An edge case is anything that happens outside the normal path, such as a wrong password, an expired link, a file that is too large or a user who has no email address. We do not hide these inside the main story. Each edge case is its own story, so it is priced, built and checked on its own.
Here is a sample to make this concrete.
Please treat the numbers as a sample only, because your own request will set its own count. A password reset might split into four stories: request the reset email, open the link, set a new password, and handle an expired link. Four stories at $5 each comes to $20. The expired link is its own story, so you can see that it costs $5 and decide whether you want it now.
Here is a weaker example.
Improve login is a sentence, not a story. It names no person, it has no reason, and there is no way to say when it is done. A reader cannot count it, and a reviewer cannot check it. The fix is to rewrite it with a person, an action and a reason, then add criteria a reviewer could check in a few minutes.
A story can be good and still be too large.
If a story has more than one action, or if its criteria read like a list of separate features, we split it. Smaller stories are easier to review and easier to count. They also make it clearer what happens if you decide to stop partway through the list.
Write the person as a role your users would recognise, such as a returning customer, a team admin or a warehouse clerk. Avoid vague roles like user on their own. A named role makes the reason easier to write and the criteria easier to test, because you can picture the screen that role will use.
Criteria should describe the result, not the steps.
The reset email arrives in the inbox is a result. Click the button, then open your mail app is a set of steps, and it goes stale the moment the screen changes. Results stay useful after the screen is redesigned, so a reviewer can keep checking the same line.
A person, an action and a reason.
Criteria that someone can check by clicking.
Edge cases as their own stories.
A count and a price you can add up before approval.
Clear stories make your reviews faster and your decisions easier
- When a story is small and clear, your reviewer knows what to look for. The reviewer opens the pull request, reads the story, and checks the criteria. The review is about one thing at a time. That is much faster than a single review of a large change where nobody is sure which part matters most.
- Clear stories also make testing easier. A criterion you can check by clicking is usually a criterion that can also be written as an automated test. The tests then keep working after the story is done, so a later change that breaks the story shows up at once. Your team gets the benefit again on every later change.
- The list is useful long after the work is finished. A new engineer can read the stories and learn what the product does and why. A product manager can see which stories are still open. An owner can see what was bought and what it delivered, in plain terms, without asking for a long report.
- Decisions get easier too. If a story turns out to be less useful than you expected, you have a clean place to say so. You can see the story, its criteria, its price and its status. You do not have to untangle one large feature to find the piece that did not earn its place.
- Stories also make it easier to say yes to a change. If you want to add a new story, you can see where it fits, what it costs and what it touches. If you want to change an approved story, ask us first. Ask us how the change is counted, and we will answer in writing before any work on it begins.
- A clear list gives your team a shared language. Everyone can point to the same line and say what it means. That shared language saves meetings, because the question is answered in the document rather than in a long discussion.
- Clear stories also help the next request start faster. A second request can reuse the same pattern for the person, the criteria and the review. Your team does not start from a blank page each time, and the reviewer already knows what a good story looks like.
- Stories also make a whole request easier to review. A reviewer can read three stories and say which one is ready, instead of reading an entire feature at once. That pace keeps pull requests moving and keeps the list honest about what is finished.
Stories compared with a ticket, a hire's backlog and an agency's scope
A ticket in your tracker is a note about work that someone should do.
It is useful, but it does not always say what done means. Two people can read the same ticket and build different things. A story with criteria removes that gap, because the criteria are written down before the work starts and checked against the result.
A hire keeps a backlog, which is a list of work waiting to be done.
A backlog is a good tool, and a strong engineer can turn it into working code. The cost is time. The engineer's time is shared across many items, and the list grows faster than one person can clear it. With stories, you pay per completed story, and the work does not wait for a single person's calendar.
An agency usually writes a scope document.
The document describes the project, sets a price and lists the deliverables. That is helpful, but the price often covers a block of time rather than a list of finished results. If a deliverable is late or unclear, the argument can run for weeks. Here the price moves with the count of completed stories, and each story has its own acceptance check.
None of these is a bad choice in every case.
A ticket works well for a small fix. A hire works well for work that needs someone on your team every day. An agency works well when you want a partner to take over a whole area. Stories work well when you want a list of clear pieces, a known price per piece and a finished result you can check.
The fair question is which tool matches the work in front of you.
If the request is small and well understood, a ticket may be enough. If the request is large and the details will change as you learn, you may want to keep a person close to it. If the request is a clear set of pieces with a clear finish for each, a story list fits well.
You can use more than one.
Many teams keep a hire for ongoing work and send well-defined requests out as stories. The story list then sits next to the rest of your process, and the price of each piece is visible to the people who approve the budget.
Weigh the total cost honestly.
A hire brings a salary, benefits and time to onboard. An agency brings a fee and a scope that can grow as the project grows. A story list brings a count and a price per completed story. Put the three side by side for one real request, and see which one matches the shape of the work.
Stories are not the only way to buy work.
They fit best when the work splits into clear pieces with a clear finish for each. When the work does not split that way, a conversation with a person may serve you better, and we will say so before you approve a list that does not fit.
Hard questions about user stories, answered in full
What counts as completed?
A story is completed when its pull request meets the acceptance criteria you approved in the PRD. The criteria are set before the build starts, so the finish line does not move. Each completed story uses $5 of your prepaid balance.
What if a story turns out to be bigger than the PRD said?
Tell us as soon as you see it. We will show you the change, the criteria it affects and how it is counted. You decide whether to keep it, split it or drop it. Ask us how a change is counted, and get the answer in writing.
What if we cannot tell what a story should do?
Say so in the request. A good request tells us who the user is, what the user should be able to do, and why it matters. If a part is still open, we can write the open part as a question for you to answer before approval, rather than guessing.
Can we see the stories before we pay?
Yes. The PRD lists the stories before any work begins. You can read them, count them and multiply by $5. The PRD lists the stories before any work begins. Payment is made in full before work begins.
How do you handle a story that depends on another story?
We put it in the PRD and mark the order. A story that needs another story to be done first is shown as dependent on it, so you can see the chain. A dependency does not change the price of either story. It changes the order in which they are built.
Do stories replace our own review process?
No. Your team reviews every pull request and decides what merges. The stories give your reviewer a clear list of what to check, so the review is faster and more focused. The decision still belongs to your team.
Can we write the stories ourselves?
Yes. If your team already writes stories in its own format, send them with your request. We will check that each story has a person, an action, a reason and criteria, and we will note anything that needs a change before approval. Your wording stays yours where it is clear.
Can we pause a request halfway?
Ask us before you pause how the remaining list is handled. We will confirm the answer in writing, so the decision is clear to both sides before anything stops.
Will the stories change once the work starts?
Work that goes outside the approved list is a change. Ask us how a change is counted, and get the answer in writing.
Count your own stories on the first request
- The best way to see how user stories work is to write one request and count it. Pick a feature you would like built. Write one sentence about it, then split it into the stories you think it needs. Count them. Multiply by $5. You now know roughly what the request would cost, before you talk to anyone.
- Then send the request to us using the button on this page. Write the way you would explain the feature to a colleague. We will reply with a written PRD, which lists each story, its criteria and its count. Set our list beside your own. The differences will show you where the request was unclear.
- Keep the PRD in your own files, whatever you decide. A clear list of stories is useful to your team no matter who builds the work. If you later choose another partner or hire someone, the stories still describe what you want.
- Your first request can be one story. The $500 minimum still applies. You will see the criteria, the check and the price, and you can judge the result against your own standard.
- Reading a PRD does not oblige you to approve it. Nothing is built until you approve, so the first request shows you how the work is split and what the checks look like. You can decide about the rest of the work after you have seen that for yourself.
One feature, written as one sentence.
The stories you think it needs, counted.
The count multiplied by $5, as a rough cost.
Your request, sent by the button on this page.
Questions, answered plainly.
Can’t find yours? Write to a founder.
1What does $5 per completed user story mean?
Each request becomes a PRD that lists its user stories, like "an admin can export the current report as CSV". A story counts as completed when its pull request meets the acceptance criteria you approved. Each one uses $5 of your prepaid balance. The minimum is 100 user stories a month, $500, paid in full before work begins.
2How do I know what a feature will cost before it starts?
The PRD lists every user story before any work begins. Multiply the count by $5, and that comes out of your prepaid balance. Nothing gets built until you approve it.
3Is this right for us?
It fits if you have a repo, a backlog, and someone who can review pull requests. It does not fit if nobody on your side can review code, because your team makes the final call on every merge.
Send the feature your roadmap has carried for a quarter.
We open the PRD the same business day. Three business days after you approve it, a pull request is in your repo. Judge us on the merge.
Minimum 100 user stories a month, $500 prepaid. No mail app? Write to udit@tinycheque.com.