User Stories Ain’t 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.