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.
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.
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.
Subscribe to the RSS feed
10 comments:
David, I believe your next to last paragraphs say it all.
"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."
Far too many sprints are executed with insufficient information..
David,
That is an interesting view. Would you also expand specification to include sufficient architecture when a story may require significant decisions to be made? I think this breakdown would help folks who are struggling to work ahead just enough in the previous Sprint to be efficient in the next.
Are the conversations also focused differently between the two? The reqs. conversation is maybe more focused on nailing down the business intent (i.e. defining the problem) and the specification conversation is more focused around determining the solution?
David Hawks
blog: austinagile.com
twitter: @austinagile
This is a great article. I was just talking with one of my clients about this the other day. The question of the week that keeps on coming up though, is: Where do design requirements come into play?
I guess it's worth the conversation!
Peter Saddington
www.whitebarrel.com
Agile-ology,
Following up on your point, executing an iteration / Sprint without being ready appears to be one of the most common agile anti-patterns!
Fortunately, once you know the problem exists you can focus on real solutions.
David Bulkin
David (or Mr. Hawks for clarity),
Per your comment, having a specification implies understanding both how the software will behave (e.g. the perspective of the user / consumer) and how it will be built (e.g. the architecture).
So, yes, I agree with you.
One key is balancing the desire to make detailed decisions at the Last Responsible Moment (LRM), with the Whole Team collaborating against the need to make the decision earlier, with select people involved, so that you can nail down specifics, understand dependencies, sign contracts, install software, etc.
This balancing act is what we are calling Sustainable Discovery (a term coined by Kevin Fisher of Nationwide), which is broad concept of readiness.
David Bulkin
It seems to me that the desire to have specifications defined before the iteration begins is somewhat of a reaction to poor Product Owner involvement during the sprint.
I think there is real value in the entire team collaborating on design specifications with the PO during the sprint. I know that this could affect the scope of the iteration and lead to some work being pulled from the sprint. But I'd rather that than have the PO (and other necessary team members) working a sprint ahead to detail stories that may not be in the next sprint, or may change significantly.
In the event that we feel there is too much uncertainty for us to size a story I prefer to introduce a "spike" story into the backlog that can be brought into a sprint for more detailed analysis.
Peter,
If I understand, the question is, when do we do design (e.g. define the “how”)?
From a terminology standpoint, at least for this blog posting, I view the design as a large part of the specification, as the definition of the “how”. This includes both external design, like user experience, and internal design, like architecture. The specification goes a beyond the design to include related items, like a list of dependencies.
In any case, the exact detail of when to first define the design, and to what extent, depends on many things including the team, the organization, the domain, and the specific requirement.
I generally propose doing the design close to the implementation. If the team is experienced, with no external dependencies, the domain is well understood and the requirement is simple, the design can be deferred until the Sprint itself.
But, per the blog post, in many instances your team will benefit by having a more mature design done prior to Sprint Planning. There are many reasons why you may need a more mature design earlier, a few examples include…
You compliance department may have to sign off on a web site design prior to implementation, and getting their approval may take more time than you have in a Sprint.
There may be many external dependencies that have to be rationalized prior to building the software.
Etc.
So, in summary Peter, I think you are right, it is worth the conversation!
Joe,
I agree that the ideal is to defer the design specifications to the iteration itself and have the team collaborate on them.
But there are instances where this just in time whole team collaboration won’t work well. As such, we will have to balance the fact that requirements don’t always age gracefully with the need for earlier definition.
For instance, assume you have a team of 15 people (I know, larger than an ideal size, but many teams are this large) and you are attempting to create an ideal user experience. We probably wouldn’t benefit from having all 15 people participate in paper testing or Wizard of Oz Testing.
Even if you had a small team, a simple requirement, etc., there still may be reasons why you would want to have the design well defined, or even done, prior to the iteration. Perhaps, for example, you need sign-off from a compliance department and the approval can take many weeks. If so, it will be hard to manage the work within the cadence of your iterations (e.g. even having a spike in iteration n-1 may not get you ready for iteration n).
So, in short, there are valid reasons for defining design specifications prior to the iteration.
David,
This a very interesting concept. Could you please elaborate on how you would handle Requirements to Test trace?
In respect to the question from anonymous about requirements to test trace, the ideal situation is that a testable example is created for a requirement soon after the requirement is created, and prior to estimation (e.g. Release Planning). The testable example specifies actual data to test with. Each requirement has zero, one or many testable examples, and each testable example is associated to one requirement.
This contrasts to more typical development where an abstract test case is created well after the requirement and associated in a many to many fashion thus making the tracing of requirement to test complex.
Post a Comment