User Stories Ain't Requirements

  1. Posted on May 9, 2013 12:12:PM by Earl Beede to Practicing Earl
  2. 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 project.

  1. Given the desire for a fixed schedule, the scope-what we will build-will flex so you don't want to call anything "required".
  2. 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 wasted.

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 work.

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 posts.)

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.

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.

Well, duh.

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.

Application said:

August 26, 2013 11:13:AM

Point taken, Earl - User Stories ain't complete requirements. But as an practitioner of agile requirements elicitation, my question is: why use such a basic (and bad) example of "acceptance criteria" for your argument about user stories? I could well oppose the classic "The system shall be easy to use." requirement....

Application said:

August 26, 2013 11:29:AM

@François, you are right, I used a silly strawman acceptance criterion. Unfortunately, it is better than many of the user stories I see in the wild that have NO acceptance criteria. And those that do are not that different from my basic (and bad) example. I want to make it very clear that just saying the story over again in a new way doesn't cut it. Neither does decomposing it to the next level of functionality (example from I can Make Toast to I can Insert Toast, Heat Toast, and Remove Toast). It is the same thing and I see that a lot. I expect that good agile requirements folks do it much better than my bad example.

Application said:

December 3, 2014 1:33:PM

It would have been helpful to see some examples of useful acceptance criteria in contrast to the "strawman" provided.

Application said:

December 5, 2014 11:48:AM

Good acceptance criteria capture the "how-well". Examples are, "No more than 3 lost records per 10,000,000 transactions" or "90% of all customer representatives can <do the story> on the first attempt in less than 3 minutes with no additional training".

Post a Comment:


Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).


Contact Earl