User Stories Ain't Requirements
- Posted on May 9, 2013 12:12:PM by Earl Beede to Practicing Earl
- user_story, Agile, humor, requirements
Ain't isn't really a word but people use it, so does that make
it de facto a word? The gurus tell us user stories are not
requirements but people keep using them that way so do we need to
treat them as requirements?
Actually, why don't we have requirements on agile projects? I
think it is because Agile is making two bets at the beginning of a
- Given the desire for a fixed schedule, the scope-what we will
build-will flex so you don't want to call anything "required".
- As the project progresses and the stakeholders see the software
come into being, the desires of the stakeholders will change.
Both bets lead to the need to limit the amount of upfront work
on items that will either 1) not be built, or 2) change. Work done
defining "requirements" upfront has a high probability of being
With no requirements, how do we get an overview of what the
project is about? How do we give the project some kind of scope
while trying to limit the amount of work that is at risk?
- Giving the project a name is requirements work.
- Setting the scope is requirements work.
- Identifying the critical delivered value is requirements
But we don't want to do all the work of getting good, complete
requirements since there is a reasonable chance that some portion
of that work will be tossed out. "What if," agile thought-leaders
must have thought while they were thinking, "What if we don't
create good, complete requirements but instead create
an approximation of the easy, lower-work part of
a requirement, the functional part?"
User stories to the rescue!
As requirements aficionados know, requirements come in two
parts: functional (actions to take, information to remember, rules
to enforce) and non-functional (how well it does the functional).
Given my analysis of thousands of requirements from hundreds of
companies, the functional part of a requirement is much easier for
people to capture. In fact, most "requirements" that I find are
just the functional part. (And are poorly formed at that. To add
insult, most are solution-oriented requirements rather than
problem/opportunity-oriented requirements. But I will save that
rant for other
A mini-template for the functional part of a requirement can be
"Actor/Action" as in the example, "The system will update the
record". The "system" is the actor and "update the record" is the
action. User stories, given the common format "As a ____ I can
_____", tend mirror a well formatted Actor/Action functional part
of requirement-the "I can" is a hint at an action to take,
information to remember, or rule to enforce. The "as a" is also
very helpful attempt to name the actor in the
problem/opportunity space though it doesn't work as well
as one would hope.
A user story is a reasonably good approximation-some may argue a
substitution-for the functional part of a requirement. Even more
handy, user stories, like any good function, can be decomposed into
sub-functions (and again into sub-sub-functions and so on). This is
one of the major things that happens in backlog grooming as we try
to get the epics broken down into a story size that can fit into a
sprint. No matter how we break it apart, though, it still is only
the functional part of a requirement and is incomplete in that it
is missing the "how well" it does the function.
So user stories are
not complete requirements.
Every project needs complete (functional and non-functional)
requirements. Where does agile project capture the non-function
parts? To be honest, too many agile projects follow their more
traditional counterparts and allow the individual developer to make
their best guess at how well the function should work. However,
there is a place to capture the non-functional "how well": the
Acceptance criteria's primary purpose is to state how we can
accept the requirement. Restating the requirement in other words
doesn't cut it, as in:
User story: As an editor, I can update the record. Acceptance
Criteria: The record is updated.
No, acceptance criteria must delineate that the function works
in a way that we can use it: how fast, how safe, how portable, how
usable, how suitable, how reliable and the other how wells
(non-functionals). These non-functional parts of a requirement are
often significantly harder than functional parts to capture and
define. Agile, in desiring to limit effort until the last
responsible moment has the product owner wait until the
user story is just about to be used but BEFORE development begins
to define most (if not all) the acceptance criteria. This assures
that the large majority of the now higher-effort complete
requirements (user story + acceptance criteria) are likely to be
used and not wasted.
So agile does have a way to capture complete and well defined
requirements prior to doing the development. It just ain't user
stories by themselves.