Why agile teams still need requirements of a different kind, how much detail is enough, and how Scrum, tailoring and agile transformations fit around them without slowing the team down.
‘We’re agile now, so we don’t need requirements.’ It’s a sentiment you’ll hear often, and it’s wrong. Agile teams need requirements just as much as traditional teams, perhaps more. The difference isn’t whether you need them, but how you write them and when. The confusion comes from thinking that all requirements must be defined upfront, in full, without involving the technical team. Agile rightly rejects that. But replacing detailed upfront requirements with no requirements simply trades one set of problems for another.
The real agile principle is just enough detail at the last responsible moment, supported by a product roadmap and a high-level design to guide daily decisions. This chapter is about applying requirements in that context. It does not re-teach how to write a requirement or how to review one as a team; those have chapters of their own. It is about the agile situation those requirements live in, and the practices that keep them useful.
What agile software development is
Agile development builds software in small, frequent increments. Instead of waiting six or more months for a finished product, an agile team typically ships a new version every two to four weeks. The most important or valuable features are identified and worked on in each increment, and users come to expect new and improved features on a regular basis. It’s not hard to see the popularity of this way of working.
Short development cycles and frequent releases bring their own challenges, though, and these require careful management. Better software requirements and solution designs are essential, along with very high testing rigour to ensure the software works as intended and without unnoticed regressions. Unlike waterfall approaches, requirements gathering is limited to the minimum required for each increment, avoiding wasted effort and future rework. Agile teams often favour user stories, a particular format of software requirement, for communicating what the software should do. Stories should be prepared in advance of each increment commencing.
When agile works best
Agile works best in situations with a high degree of uncertainty. A good example is trying to enter a highly competitive, saturated consumer market where product differentiation and uniqueness are key. You may have a well-researched hypothesis, but determining every feature six months in advance is an endeavour fraught with danger. You simply can’t know how your proposition will fare in the marketplace.
Agile has you build the most valuable or risky things first, and only to the extent required to test the concept for real. Don’t code for six months if you can code for two and release to some actual users. Ask them what they think, check if they use it, decide if you should continue, make the necessary adjustments and fine-tune the roadmap. Better yet, ship new versions even more frequently if you can, increasing the rate of user feedback and reducing the risk of getting it wrong.
What limits agile
There are numerous reasons agile fails to deliver on its promise, but a command and control approach is the most significant limiting factor in my experience. Organisations are fundamentally structured top-down, with planning and budgets allocated upfront, in advance. Managers need to explain what they are building, often in detail, before funding is released. Test and learn approaches get squashed, and agile becomes nothing more than a waterfall delivery sliced into two-week intervals. User feedback that contradicts the upfront planning assumptions is ignored or deferred, so the 12-month plan remains on track.
This matters for requirements because requirements are only as good as the process they are used in. A team that has been told what it will build for the next year does not need just-enough requirements written at the last responsible moment. It needs a year of specifications written upfront, which is the very thing agile sets out to avoid. So before adjusting how you write stories, it’s worth being honest about whether your organisation actually wants the thing it says it wants.
Are requirements still agile
Software requirements and solution designs are even more critical for good agile development, not less. Just enough detail at the last responsible moment is the right approach, supported by a product roadmap and an overarching high-level design to guide the team in their daily decision-making.
Better requirements, in the form of agile user stories, are valuable precisely because they keep work moving. Having stories prepared ahead of developers picking them up prevents that work from becoming unexpectedly blocked. Not bothering with user stories only works when you have a well-rounded developer physically sitting next to the product owner, both happy to have conversations throughout the day as the work progresses. That’s an excellent arrangement if it’s your situation, but it’s rare in modern development, where teams are distributed across offices, time zones and continents.
Non-functional requirements in agile
Non-functional requirements deserve a particular mention in an agile setting. Performance, accessibility, security, scalability and reliability usually apply to the whole product rather than to individual stories, so don’t repeat them in every story. Document them centrally and reference them from individual stories when relevant. This keeps each story focused while ensuring the critical quality attributes aren’t quietly forgotten.
Read more: Functional vs Non-Functional Requirements
How much detail is enough
This is the hardest question in agile requirements, and there’s no universal answer. Some teams thrive on three-sentence user stories; others need far more. Both can deliver good software. The appropriate level of detail isn’t really a property of the requirements at all — it’s a property of your team, your domain and your constraints. The way to find it is to watch for the symptoms of getting it wrong in either direction.
When you haven’t written enough
You’ll know you’ve under-specified when developers keep getting blocked. They pick up a story, start working, hit a question they can’t answer themselves, and stop. Then they’re waiting — for you to respond, for the product owner to return from meetings, for a stakeholder to make a decision. The further apart your team is, the more expensive each of these pauses becomes; a distributed team can lose most of a sprint to questions that each take a day to answer.
You’ll also see rework spike. Developers build something, show it in the demo, and stakeholders say ‘that’s not what we meant.’ Technically the developers met the requirement as written, but the requirement didn’t capture what stakeholders actually wanted. And you’ll see the product owner overwhelmed with clarification requests. If they’re spending most of their time answering questions instead of planning ahead, the requirements lack essential detail.
When you’ve written too much
Over-specification looks different but feels just as wrong. Requirements start to read like implementation manuals, dictating how the work should be done rather than stating what needs to happen. Developers stop thinking and start following instructions. They implement what you wrote, even when they can see a better solution, because you’ve clearly decided everything already. The worked example of where that line sits is in Writing Requirements, and isn’t repeated here.
The real cost is that you’ve stolen their expertise. Good developers know interaction patterns, accessibility standards and performance trade-offs; over-specification prevents them from applying any of it. The work becomes soul-destroying, and your best developers will be the first to leave.
Finding the right balance
Experienced developers in small co-located teams with direct user access need minimal documentation. They can clarify questions in real time, their shared context fills in the gaps, and they’ve got the judgement to make good decisions independently. Junior developers in large distributed teams building unfamiliar domains need much more support. They can’t tap someone’s shoulder, they haven’t built up pattern recognition for common scenarios, and they don’t have enough context to decide well on their own. These teams need detailed requirements, not as criticism but as appropriate scaffolding. Distributed teams need more of this, not less, which is the subject of Remote, Offshore and Outsourced Teams.
Domain complexity matters too. Simple features in familiar territory need less specification; complex features in novel domains need more. Another routine screen needs only a quick story. Complex business rules for financial calculations in a regulated industry need real detail.
Tailoring your agile process
You should tailor your agile process, because requirements are only as good as the process they’re used in. A well-functioning agile process is the foundation, and getting it right involves rolling up your sleeves and really understanding the specifics of your team’s development process and the organisational context they work in. Defining the right requirements, at the right time, to the right level of detail, for the development team you actually have is what’s required — and tailoring your choice of agile framework is how you discover the winning combination. Make small, incremental changes and observe the result over time. Adjust as necessary.
A few agile-specific suggestions to get you started. Decide whether stories must be refined ahead of the current sprint or can be picked up and refined at any time — both are valid team choices. And avoid writing stories too far in advance; deliberately keep the backlog small and fresh. A product owner who spends three months writing a year of detailed requirements will watch half of them become irrelevant the moment real user feedback arrives.
The mechanics of preparing those stories — what a user story should contain, the what-not-how rule, the 80% of content that is acceptance criteria, and the developer-and-tester review that makes a story ready — belong to Reviewing Requirements and aren’t repeated here.
Tailoring versus changing
There’s an important difference between tailoring a framework and changing it. Tailoring is making changes within the rules or guardrails of the framework you’re using, so that its integrity remains intact. More frequent refinement sessions, a different sprint duration, a new estimation approach: these are all valid tailoring you could perform within Scrum.
Choosing to deliberately ignore the rules, or to substantially modify the practices the framework requires, is tantamount to changing it, ie. creating something new. Working without timeboxed increments, not holding planning sessions, not agreeing on a sprint goal: these are changes that would render a Scrum process no longer Scrum (nb. sometimes referred to as a ‘Definitely Not Scrum’ framework).
Changing a framework isn’t necessarily bad, but it does introduce a divergence in thinking and practices. For an established, well-functioning team it’s likely a sign of maturity. Many less experienced teams, though, would do better to examine their motivations more closely and work to improve within their framework of choice first. An experienced agile coach or external facilitator on hand to help is invaluable here.
Scrum
Scrum is an excellent way to build software, and I’ve had many good experiences with it. It’s fairly prescriptive, fosters good planning, promotes transparent communication and sustainable development practices, and requires whole-team inspection points for improvement. That’s the kind of Scrum I know and I’m familiar with.
Unfortunately, it doesn’t take much for Scrum to become a developer’s worst nightmare, eg. micromanagement, feature factory development, loss of creativity, unsustainable sprinting and surface-level ceremonies. An excellent Scrum Master or agile coach can foster the right conditions for true agile working and protect your development team from experiences like these.
As for bespoking it, honestly I wouldn’t recommend it. The prescriptive nature of Scrum provides an excellent framework for most teams to work within: plenty of useful guardrails are built in, while retaining the flexibility to experiment. You should be able to go a very long way on just plain old vanilla Scrum. Teams that need to scale in size should reach for a scaled framework rather than bespoking Scrum. I’ll make an exception for teams who have fully mastered Scrum and now feel their potential is constrained by the framework itself, but I haven’t come across many of those in my career.
Agile transformations
Some organisations don’t want agile. They say they do, but shop floor behaviour indicates otherwise. Unless the CEO has personally spearheaded agile ways of working, small autonomous cross-functional product teams who release software frequently and practice continuous improvement are aspirational at best. Agile remains one small initiative in the product or technology department, ready to be overridden, deprioritised or ignored when something more important comes along. This is the reality of building software in large enterprises, particularly those not in the business of technology.
Developers find this incredibly confusing, particularly when an agile coach espouses individual empowerment and bottom-up transformation in an organisation that acts otherwise. The internal conflict of trying to work one way while being inadvertently prevented from doing so can cause irritability, tiredness, fatigue, burnout and poor mental health. High levels of staff sickness and turnover are good indicators of it.
Software requirements are the antidote to confusion, ambiguity and undue personalisation. Slice the requirements thin, call them user stories, practise story refinement, get a solid definition of ready, adopt a rigid Scrum cadence and ask the agile coach to protect your boundaries. None of this fixes an organisation that doesn’t want agile; only the CEO can do that. But it gives the team a stable structure to work within while the larger question is settled above their heads.