How to develop requirements as a team rather than in isolation: running review sessions that work, making requirements testable, and the Definition of Ready and Definition of Done to hold them to.
Requirements as ongoing conversation
Software requirements aren’t something that get written and handed over to the technical team, never to be discussed again. Rather, they are actively ‘developed’ over time in a process best seen as an ongoing conversation between users, developers and testers (nb. often a business analyst or product owner is the proxy for the user in this arrangement).
The technical team should be involved fairly early in reviewing the emerging software requirements and consulting on the feasibility of building such things. Their involvement helps form an opinion on the classic ‘iron triangle’, ie. time, cost and features. Management are usually very happy for an informed view, and any estimates can be revisited as the software requirements become better known.
How to run effective review sessions
Software requirements are best reviewed as a team in frequent, regularly scheduled review sessions. Once or twice a week usually works well for a team of up to 5 developers. The idea is to ensure each software requirement has been reviewed before development commences so that significant clarifications have been bottomed out. Incomplete, ambiguous and poorly written requirements should be identified quickly and marked as unsuitable for development.
Practically, here’s how to conduct a good review meeting. Open each software requirement and have someone read it aloud to the team. Each person should use their professional expertise to assess what they hear critically. Is the requirement clear and unambiguous? Are business rules, edge cases and third-party dependencies known? Do we know enough to build and test it? If not, are we still happy for a developer to commence working on it? These are all good questions to ask. Developing a standard set of review questions together as a team is often a helpful exercise.
User story best practices
A developer and tester should review each user story together. Only once both are satisfied should the story be considered ready for development.
User stories should focus on what the software needs to do, rather than how it should be done—leave implementation decisions to developers. Acceptance criteria usually makes up 80% of a story’s content. This is where you clarify what “done” means, not in prescribing technical solutions.
When reviewing, ask: Can a developer build this without getting blocked? Can a tester verify it independently? If yes, the story is probably ready. If no, more detail or context is needed.
Making requirements testable
A requirement is testable when a tester can verify it independently — confirm whether the software does what was asked without having to go back to the author and re-interrogate them about what was really meant. If the only person who can tell whether the work is finished is the person who wrote the requirement, the requirement isn’t testable yet.
Acceptance criteria are the unit that turns a requirement into a test. Each criterion describes an observable outcome a tester can check, which is why ‘done’ has to be verifiable rather than aspirational. ‘The screen should be intuitive’ cannot be tested; ‘a first-time user can complete checkout without help in under two minutes’ can. The same discipline that makes a requirement clear enough to build makes it clear enough to verify — the two move together.
So when a tester can’t write a test from the requirement, treat that as a signal about the requirement, not the tester. It means an outcome is missing, an edge case is unstated or a business rule is still implicit. The fix is to develop the requirement further until the test writes itself — which is precisely the work the review session exists to do.
Definition of Ready
Before developers start work, stories should meet clear “ready” criteria. Create a checklist and don’t allow development to begin until all boxes are checked.
Essential ready criteria:
- Acceptance criteria clearly defined
- Dependencies identified and available (or scheduled)
- Business rules documented explicitly
- Edge cases and error scenarios considered
- UI designs attached (if applicable)
- Test scenarios outlined
- Team has reviewed and understood the story
- Estimated (if your team estimates)
Stories failing these criteria stay in the backlog. No exceptions.
Struggling to get enough stories ready? This indicates upstream activities need more effort: user research, product planning, and requirements gathering. In my experience, teams that hit this wall consistently have the same underlying gap — user research and product planning aren’t keeping pace with development. Don’t pressure developers to work on incomplete stories. Fix the pipeline, not the developers.
Definition of Done
Similarly, define what “done” actually means. When can you confidently mark work as complete?
Essential done criteria:
- Functionality complete and working
- Code reviewed by another developer
- Unit tests written and passing
- Integration tests passing (if applicable)
- Acceptance criteria verified by tester
- Documentation updated (if needed)
- Deployed to test environment
- Demo-ready (can show working software)
Stories meeting functional requirements but failing quality criteria aren’t done—they’re technical debt waiting to bite you.
Some teams add additional criteria: accessibility tested, performance benchmarks met, security scanned. Adapt these lists to your context, but make them explicit and non-negotiable.
The goal isn’t bureaucracy—it’s shared understanding. Everyone knows what “ready to start” and “actually done” mean without ambiguity.
Backlog management
Decide whether stories must be refined ahead of the current sprint, or if they can be picked up and refined at any time. Both approaches work. Choose what fits your team’s rhythm.
Avoid writing stories too far in advance. Requirements change. Priorities shift. Detailed stories written months ahead often become outdated before they’re built. Keep the backlog deliberately small—enough for 2-3 sprints ahead, not the entire quarter.
The Definition of Ready and Definition of Done matter even more once a team is distributed, where a shared, explicit standard substitutes for the casual clarifications a co-located team picks up in passing. That case is developed in Remote, Offshore and Outsourced Teams.
Handling specialised reviews
Unfortunately, some developers can quickly become bored when asked to review requirements that have little relevance to their specialised skillset. The solution is to triage all new software requirements as a team, identifying what technical skills will likely be required to build each requirement. Reviews are then performed in smaller breakout sessions with only the relevant parties. Sometimes, these reviews are performed ‘offline’ or asynchronously through ticketing systems and collaboration platforms. Either way, ensure that testers are always involved, irrespective of how reviews are conducted or the technical skills required by the software requirement.
Iterative refinement
Often, the same software requirement goes through several rounds of reviews, successively clarifying and elaborating it each time as more becomes known. The result isn’t a detailed specification, unless you are manufacturing an aeroplane engine; rather you are gathering together enough information for each requirement so that developers can resolve the remaining details themselves and work without becoming blocked. Better software requirements are best described as ‘developed’ rather than ‘written’.
Read more: Card, Conversation, Confirmation