Service Design and Agile Requirements Definition
Service Design and Agile Requirements Definition
This domain tests requirement formats and, more importantly, whether a requirement can actually fail a test. Agile requirements are conversations made durable by acceptance criteria, refined just in time.
Core constructs
- Epic, story, task: an epic spans sprints, a story delivers value within one, a task is internal work with no standalone customer value.
- Story format: As a role, I want a capability, so that an outcome. The 'so that' is the value hypothesis and is not optional.
- INVEST: independent, negotiable, valuable, estimable, small, testable.
- Acceptance criteria: Given/When/Then for behaviour, a rule checklist for business logic. If you cannot write a criterion that could fail, the story is not ready.
- Definition of Ready (entry) and Definition of Done (exit). Done should include service criteria: monitored, documented, support-trained, rollback tested.
- Non-functional requirements: capacity, availability, security, recoverability, compliance. Express them as measurable constraints with a named verification method.
- Techniques: personas; story mapping to expose gaps across the user journey; service blueprints showing frontstage, backstage and support processes with failure points; three amigos from business, development and testing agreeing criteria before building.
Worked example
'The portal must be fast and reliable' is untestable. Rewrite as: 'Given a signed-in customer, when they search the catalogue, then 95% of responses return within 400 ms at 200 concurrent users', and 'the service is available 99.5% per calendar month, measured at the load balancer'. Add verification: load test in the pipeline, synthetic monitoring, a monthly report. Reasoning: each clause now names a condition, an observable measure and a checking method, so the criterion can fail - which is precisely what makes it a requirement rather than a wish.
Traps
Stories written as technical tasks ('add an index'); NFRs deferred to a hardening phase; acceptance criteria that merely restate the story title; using Definition of Ready as a gate that blocks flow instead of a refinement target; forgetting supportability and operability in Done.