In the agile community we focus heavily on user stories as a way of organizing our needs, but many make the false assumption that a user story, in itself, is sufficient as both a requirement and a specification.
The reality is that a user story is not a requirement, it is what helps you remember, organize and talk about a requirement. Taking this further, a requirement is not a specification, and you often need a specification prior to building.
What Constitutes an Agile Requirement?
A requirement is a user story, plus acceptance criteria, plus a conversation.
Generally speaking a requirement is enough information to make a point based estimate. This is often true even when the requirement is large grained (think epic or feature). But, a requirement is not sufficient information for most teams to start building. So prior to Sprint Planning there is a good chance you will need a specification.
What Constitutes an Agile Specification?
A specification is a requirement, plus additional supporting material as necessary, plus a conversation.
The determination of what supporting material is appropriate is highly dependent upon the team and the requirement. For example, a UI intensive application will often require one or two of:
- concrete example (e.g. testable example)
- wire frame
- pixel perfect rendering
- dependency list
- interaction diagram (flow)
- etc.
As you are thinking about the supporting material, try to create the minimal amount of supporting material in the lightest weight way, to provide the information the team needs. Remember, if a short conversation and a drawing on the back of a napkin is enough, don’t create anything more (e.g. we don’t want mini waterfalls with heavyweight documents).
How Does This Impact the Way We Work?
Generally speaking we find that far too many teams make estimates on user stories (without acceptance criteria) and then start building against requirements (without specifications). The result is poorly executed Sprints.
In most cases, you should have requirements ready prior to Release Planning (.e.g. prior to estimating) and have your specifications available prior to Sprint Planning (e.g. prior to building). If the requirement is simple enough, or the team is experienced / jelled enough, you can create the specification itself in the Sprint.
As always, I appreciate your feedback and input.
