The easy answer is anywhere you want.
Relevant at the Activity Level
Non-functional requirements (NFRs), also called quality constraints, seem most relevant at the activity level on the map. With a map on the wall you might write them as bullets on an existing sticky note for an activity , or place them next to the activity on a new sticky. If there are too many NFRs, you could create a column for them under the activity with a heading of “activity characteristics.”
Sometimes, people insist that an NFR is true of the whole system. When that happens, you can point to an activity and ask, ”is it true here? …and here? …and here?” We usually find that the answer, and therefore the NFRs, vary with the user’s activities.
Story Map Evolution
Story maps work best if the structure can be ad hoc and situation specific. Invent the structure you want, to describe the system you want. That’s perfectly OK. Story maps are initially used to describe user’s behavior. As you move closer to building the product, the map describes their behavior with the product. The map will then evolve to describe only the product.
The map is built out of lots of little sticky notes. Each one of which can potentially be a story. The sticky truly becomes a story when you schedule it into a sprint, and pour out the contents into the product.
A Story is Like a Bottle
When Jeff was teaching recently in Japan, these same questions regarding NFRs came up. Since it was after class in Japan, there was beer. So the beer bottle became our metaphor for a story.
A user story is like a bottle. It’s a container that holds something. I can put a label on the outside to identify it. I can arrange them on shelves and walls. And then, I’ll pop the top and pour it into our software. Then the bottle is empty. What gets poured out of the bottle needs to change our software in some way. Story tests check that we changed it in the way we expected.
Testing the Constraint
NFRs can be story tests on some content we poured into the product. They’re constraints to check that the software is done. A story to “log in” may have a NFR that 1,000 users can log in simultaneously. Before calling it done we’ll have to devise some way of testing the constraint. Once we’ve tested the constraint for that one story, you can see that as we pour more beer into our drunken system, we can’t guarantee that constraint will always be met. Unless we keep testing with every story poured in after that. That sounds like a real pain.
We could write a story specifically to test for a particular NFR. We could schedule that into a sprint, pop the top, and test it. We’d want to be sure the NFR was always met, testing it every so often. I could write some automated testing around NFRs, pouring it into the continuous integration server, or a regression test suite.
Keep Them Visible
Finally, I suspect the real concern for many is, “What if we forget about these constraints?”. All I can say is, don’t do that. Use a map or some other model and keep it visible. Keep it as part of the discussion. It’s a product ownership responsibility to pay attention to continuously. There’s no wall to throw it over.
- Hayim Makabee on Consequences of Thinking, Fast and Slow – Blog Series
- Ben Linders on Evaluate Process Qualities, not Process Compliance
- Der perfekte Product Design Sprint - die besten Methoden für kompakte 5 Tage | produktbezogen.de on Describing Agile Product Discovery
- Colin Claverie (@Coclav) on Evaluate Process Qualities, not Process Compliance
- Aaron Sanders on Consequences of Thinking, Fast and Slow – Blog Series