Working with developers: specs, estimates, sprints and acceptance criteria

Many founders’ first experience of hiring developers follows a familiar pattern. A brief goes out, a quote comes back, work starts, and three months later the product is late, over budget and not quite what was imagined. Usually nobody was careless. The brief left room for different readings, the estimate was treated as a promise, and nobody agreed what “done” meant.

This guide covers four tools that fix most of that: clear specifications written as user stories, honest estimates, short sprints, and acceptance criteria. They work whether you hire a freelancer, an agency or your own team.

Write specs as user stories

A specification tells developers what to build. Long documents written up front tend to go stale, so many teams break the work into user stories: short descriptions of something a user needs, written from their point of view.

The UK Government’s Service Manual guide to writing user stories suggests this format:

As a… [who is the user?] I need/want/expect to… [what does the user want to do?] So that… [why does the user want to do this?]

For example: “As a returning customer, I want to reorder a previous order in one click, so that I can restock quickly.” The “so that” part matters most. It tells developers the goal, which lets them suggest simpler ways to reach it.

The Service Manual adds that large stories, ones “that would take more than a few weeks to develop and test”, are called epics, and should be split into smaller stories “that can be completed within an iteration”.

A common check for a good story is INVEST. According to the Agile Alliance’s glossary entry on INVEST, proposed by Bill Wake in 2003, a story should be Independent, Negotiable, Valuable, Estimable, Small and Testable. If developers can’t estimate a story or you can’t test it, it needs more work before anyone builds it.

Add acceptance criteria to every story

Acceptance criteria are the conditions a story must meet to be accepted. The Service Manual describes them as “a list of outcomes that you use as a checklist”, often written as a list starting “it’s done when…”.

For the reorder story, acceptance criteria might be:

• A “Reorder” button appears on each past order in the account page.
• Clicking it adds all items still in stock to the basket at current prices.
• Out-of-stock items are listed with a message and are not added.
• The feature works on mobile and desktop.

Criteria like these settle arguments before they start. They also make testing straightforward: each line is something you can check.

Acceptance criteria are specific to one story. A definition of done applies to all work. The Agile Alliance describes the definition of done as “a list of criteria that must be met before a product increment” counts as complete, agreed by the team and kept visible. A typical one might include code reviewed, tests passing, and deployed to a test environment. The Scrum Guide is firm on this: “If a Product Backlog item does not meet the Definition of Done, it cannot be released”.

Treat estimates as forecasts, not promises

Founders need estimates to plan budgets and launches. Developers know estimates are uncertain, especially for work nobody has done before. Both are right, and the way through is to be explicit about uncertainty.

Many agile teams use relative estimation. The Agile Alliance’s entry on relative estimation describes estimating stories “by comparison or by a grouping of items of equivalent difficulty” rather than in hours. It lists benefits such as avoiding “unwarranted precision” and not “confusing estimates for commitments”, while noting that evidence that people estimate better this way is only tentative. Teams may use points, T-shirt sizes or planning poker, where each person reveals an estimate at the same time.

The UK Service Manual’s guidance on planning in agile suggests matching detail to timing: “Plan work you do not expect to do for a while at a high level” and make “a more detailed plan for work you are just about to do”.

Practical ways to get better estimates:

• Ask for ranges, not single numbers, and ask what would push it to the high end.
• Split big items before estimating. Small stories estimate better than epics.
• Pay for a short discovery phase on risky or unfamiliar work before asking for a fixed price.
• Track actual time against estimates and use the history to plan.

Work in short sprints

A sprint is a fixed period in which the team builds a set of agreed stories. The Scrum Guide defines sprints as “fixed length events of one month or less”, and many teams use one or two weeks. Each sprint has a sprint goal, “the single objective for the Sprint”, agreed at sprint planning.

The rhythm gives a founder regular control points:

1. Sprint planning: agree the goal and which stories are in.
2. Daily check-ins within the team to spot blockers.
3. Sprint review: see working software, not slides, and give feedback.
4. Retrospective: the team discusses how to work better next time.

Your job in this rhythm is closest to what Scrum calls the Product Owner, accountable for “maximizing the value of the product”. In practice that means keeping the list of stories ordered by priority, being available to answer questions, and turning up to reviews. A project slows down quickly if the client disappears between kick-off and launch.

A worked example

An example (illustration only). A founder of a small cleaning company wants an online booking system. Instead of a 20-page brief, she writes 15 user stories, each with acceptance criteria, and orders them by importance. The top five cover choosing a service, picking a slot, paying and receiving a confirmation.

The agency estimates each story as small, medium or large and gives a range for the first five: two to three two-week sprints. They agree a definition of done: reviewed, tested on mobile, and deployed to a staging site she can try.

At the first sprint review she tries the booking flow and spots that customers need to add access notes for the cleaner. It becomes a new story for the next sprint. After three sprints the core booking flow is live. Lower-priority stories, such as discount codes, wait until real bookings show whether they are needed.

Common mistakes

• Writing solutions instead of needs. “Add a dropdown” constrains developers; “customers need to choose a time” lets them propose the best option.
• Vague acceptance criteria such as “works well” or “looks modern”.
• Treating an estimate as a fixed quote. If you need a fixed price, fix the scope too and expect a margin for risk.
• Skipping sprint reviews. A problem spotted in week two is usually far cheaper to fix than one found at launch.
• Changing priorities mid-sprint. Add new ideas to the backlog and pick them up at the next planning session.
• No definition of done, which leads to features that are “done” but untested or not deployed.

When this approach fits

User stories, sprints and acceptance criteria suit products where needs will change as you learn, which describes most start-ups. For small, well-defined jobs, such as fixing a known bug or adding a standard plugin, a short written brief with clear acceptance criteria and a fixed price is often enough. Keep the acceptance criteria either way; they are the cheapest insurance you can buy.