Running agile delivery inside a fixed budget
Fixed budgets and iterative delivery are compatible if scope is the variable. Fixing all three is what causes trouble.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Requests are usually solutions — find the decision behind them.
- Observation reveals workarounds that interviews miss.
- Ask about the last unusual case, not the general rule.
- Write scenarios with outcomes, not abstract statements.
Requests are usually solutions
“We need a dashboard” is a proposed solution. The underlying need might be a weekly figure, an alert when something goes wrong, or confidence that a process is running.
Ask what decision the thing informs and what happens today without it. That frequently produces a smaller, cheaper answer than the one requested.
Watch the work
People are unreliable narrators of their own processes — they describe the intended process rather than the actual one, and omit the workarounds they no longer notice.
Sitting with someone for an hour reveals the spreadsheet, the second screen and the printed reference sheet. Those artefacts are requirements, and they are more reliable than any interview.
Get to the exceptions
- How often does the standard path not apply?
- What do you do when the data is missing?
- Who decides when the rules conflict?
- What was the last unusual case, and how was it handled?
The last question is the most productive one in requirements gathering, because it produces a concrete example rather than a generalisation.
Write it where it can be challenged
Capture requirements as scenarios with expected outcomes rather than as abstract statements. Concrete examples are easy to confirm or correct; abstractions get agreed and interpreted differently.
Circulate them to the people who described the work. Reading their process back to them surfaces misunderstandings while they are still cheap.
Writing requirements people can verify
Requirements are only useful if their satisfaction can be judged. “The system should be user-friendly” cannot be verified; “a trained operator can complete a booking in under two minutes” can.
Write each requirement with an acceptance condition. Where the condition is hard to express, that usually means the requirement is not yet understood, which is worth discovering now.
Include the non-functional requirements explicitly — performance, accessibility, retention, audit. Discovered late, these are among the most expensive things to retrofit.
Frequently asked questions
Long enough to understand the problem and the exceptions typically a few weeks for a substantial system. Rushing it is the most expensive saving available.
The people who do the work, the people accountable for the outcome, and whoever will have to support it. Involving only management produces requirements describing the intended process.
Expect it. The aim is not to fix requirements permanently but to understand enough to start, and to structure delivery so change is affordable.
