A common challenge with writing user stories is how to handle a product’s non-functional requirements. These are requirements that are not about specific functionality (“As a user of a word processor, I want to insert a table into my document.”), but are rather about an attribute or characteristic of the system. Examples include reliability, availability, portability, scalability, usability, maintainability. As you can see from that list, non-functional requirements are often referred to as “-ilities”. Of course, not all non-functional requirements end in “-ility.” We also have security, performance, robustness and so on.
Thinking back into the dark ages, I can remember when I first read about “non-functional requirements.” The term threw me for a loop. “If it’s non-functional, why do I care about it?” I’m sure the author of that book clarified this for me a page later, but the term has always seemed an odd one to me. I prefer to think of non-functional requirements as “constraints” we put on the system. When a product owner says “this system must perform adequately with 100,000 concurrent users” the product owner is putting a constraint on the development team. The product owner is effectively saying, “Develop this software any way you’d like as long as you achieve 100,000 concurrent users.” Each constraint we put on a system narrows the design choices a bit; calling these “constraints” rather than “non-functional requirements” helps us remember this.
Fortunately constraints / non-functional requirements can be easily handled as user stories. Here are a couple of examples:
- As a customer, I want to be able to run your product on all versions of Windows from Windows 95 on.
- As the CTO, I want the system to use our existing orders database rather than create a new one sot that we don’t have one more database to maintain.
- As a user, I want the site to be available 99.999% of the time I try to access it so that I don’t get frustrated and find another site to use.
- As someone who speaks a Latin-based language, I might want to run your software someday.
- As a user, I want the driving directions to be the best 90% of the time and reasonable 99% of the time.
As you can see from these I was quite easily able to stick with the “As a <type of user>, I want <some goal>, so that <some reason>” template that I prefer for most user stories. I do this for a couple of reasons but want to comment further on only one of them here. Consider the example of the CTO constraining the team to use the existing orders database. (This was the real situation; the team was considering a second orders database that would be sychronized at night. The CTO overheard this and said “no!”) If we wrote this requirement as simply “Must use existing orders database” it would be entirely possible that a few months down the road we wouldn’t remember why we should be constrained in that way. We’d ask the product owner if she cared if we used a secondary database, and she’d say she had no objections. And we’d make a mistake of using one. Embedding the person who wants something can be very useful.
But, you should be careful not to get obsessed with that template. It’s a thinking tool only. Trying to put a constraint into this template is a good exercise as it helps make sure you understand who wants what and why. If you end up with a confusingly worded statement, drop the template. If you can’t find a way to word the constraint, just write the constraint in whatever way feels natural
Hi Mike. Thanks for the post.
Here is my question for you… what sprint do you schedule these “user stories” into? As you said, they are a constraint, they are a design decisions that impact every story on the backlog.
So.. if that is the case, does it make sense to put them into the backlog or should we come up with some other mechanism?
If you create a user story, and that user story is in with all the others, it’s very nature would result in it being managed differently. It would never get explicitly scheduled into a sprint. I am not sure this approach adds value.
I would rather keep all non-functional requirements/constraints on a sharepoint site, a wiki, or even on a card on the wall; and reference that requirement in each backlog item where it is applicable.
Thoughts?
Thoughts?
Mike–
That’s a great question and I do have a good answer for it. I don’t have time to write it up right now. Also, it’s a big enough topic that I’ll save it for the next blog posting, which I’ll try to get up here in a week or two. Sorry for the delay.
Mike,
We used to write our non-functional requirements as you suggest, but the problem that we always had was how to come up with a satisfactory ‘definition of done’. In other words if we schedule such a story can we really close it at the end of the sprint? The cross-cutting nature of requirements such as i18n, security, availability, etc. means the effort is ongoing throughout the duration of development.
Perhaps ensuring these abilities exist in a product is best achieved using an approach similar to the way that code quality is currently measured via CI. In other words, by setting targets (e.g. 90% test coverage) and monitoring over time?
J
As a project member,
I want non-functional requirements expressed as user stories,
so that it is clear to everyone what the value of the requirement is and who values it.
I have this pattern. I’ve even used it further:
As a student on the course
I want to learn the practices in scrum
So that I can decide what method is appropriate for my projects
(Actual requirement from a short training course I gave earlier this month)
We realized the value of this approach on my last project
As a ….?
I want the project to use WebSphere
So that ….?
When nobody could fill in the blanks, getting rid of the monster was an easy decision. But it took us a long time to get there.
Johnstok–
I used to think that one of the things that distinguished a constraint (non-functional requirement) was that “once a team accepts it into the project they have to live with it forever.” For example, during the first iteration of let’s say a year long project we are not going to spend a lot of time on performance testing–there’s hardly anything to test the performance of. Maybe 3-4 iterations in we decide it’s time to start taking performance testing seriously. We’ve been coding with performance in mind but not yet testing to verify it. Well, once a team accepts that performance testing story, they need to live with it forever. Ideally they will do a full performance test every iteration from then on. (In practice, they may opt to do so every 2-3 iterations just to save on the time and cost of doing so if they don’t think a given iteration affected performance.)
Deciding when to pull a constraint into the project is not as simple as deciding to develop a “regular” user story. A regular user story has very little ongoing cost (unless we break it!). The example above about adding a table to a word processor is a good example. That costs (let’s say) 5 person-weeks to develop, including some great automated tests. That’s it. That feature is done and paid for–you own it. Performance testing (as an example of a constraint) is not so easy. You pay part now in the form of the work to create and run the tests initially *and* you pay more every iteration. This is why the common view on this is to consider that a tax on the development team: The team will spend x hours per iteration keeping the system at the performance level agreed upon.
(BTW, this is getting at the question that Mike asked earlier and above)
This makes estimates of constraints harder. Continuing with the performance testing example, it may be the case that adding that in during iteration 3 is cheap (4 person weeks) but we’d be paying that tax for a long time (another let’s say 23 iterations for a 26 iteration x 2 week = 1 year project). Alternatively we could delay pulling the performance testing story in until say iteration 16. It will then be expensive; say 11 person weeks, but we’ll pay the tax for only 10 iterations. The tax might be greater because we might uncover more areas with subtle performance issues and interactions. And there’s not just two options, it’s obviously a continuum of choices. This is what makes estimating and planning for a constraint (non-functional requirement) harder.
I like this idea quite a bit. This has always been a sore spot for our team. “There was no story to make it fast”. Of course we weren’t really using Scrum correctly in the first place so things are improving now, but these types of things always bring rather large gray areas.
We typically try and deal with constraints on a story level but that doesn’t cut it when you’re building a complete system.
I like the idea of writing these NFR user stories on the wall and posting them in the work area as a reminder that the team should factor those constraints in when giving estimates.
Thanks Mike, this comes just in time as we’re preparing to start new development on a new product.
Scott Ambler wrote some nice articles in DDJ about how to manage these constraints.
* Beyond Functional Requirements On Agile Projects : http://www.ddj.com/architect/210601918
* Complex Requirements On an Agile Project : http://www.ddj.com/architect/211800534
Emmanuel
I like the idea of capturing the NFR/Constraints in the story format. However, for some constraints like meeting some performance/scalability goal could not be easily scheduled as a story to work on. Because it is the functional stories that these constraints impact. As a result, we need to associate these NFR stories to the functional stories. The way I handle this is that I identify functional stories that are “architecturally significant” and include the NFRs as constraints in those stories. I try to schedule architecturally significant stories early in the project so that we can build out the architecture foundation through the functional stories. If it happens to be scalability, we would use load testing as a way to validate. We may not achieve the goal in the first go. We can spawn more targeted functional/NFR stories as needed to close the gap between the current performance and target performance.
I quite agree with the idea of regarding “Non-functional requirement” as constraints. I published a post (http://www.googlecom) about how to handle non-functional requirement in an agile project with a story card template. Meanwhile, it was quite challenging on how to divide the non-func story into small unit of constraints and how to manage them in a functional story level. Fortunately, we practiced in projects by this way which made quite successful.
Considering non functional requirements as constraints is a good thing – however, I’m not convinced these are all best recorded as user stories?
For example, if as part of my system we have a non functional requirement to ensure a suitable level of performance is maintained, we would currently express this as acceptance criteria on the relevent stories for the vertical slice we are working on within a sprint.
As we ramp up the number of users and increase functionality, this performance constraint will equally grow – again, the stories to deliver each extra feature from the customer’s perspective will also include acceptance criteria to ensure it carrys the required level of performance.
At the lower level we might break this performance AC into a specific story or task, but we haven’t captured it as a story in its own right.
The reason for this is that if we have a story “suitable performance” – there is no concept of “done”. What done is changes with each vertical slice we deliver. Its for this reason we capture NFR as AC at the release level, breaking them to tasks in the iteration.
Sarah–
Good points. What I normally do in this situation is hang the constraint cards on the wall so that they are always visible. Then those constraints are in the team’s mind as they plan a new sprint. And yes they can add conditions of satisfaction (COS) to a user story to convey any implications of the constraints already accepted into the project.
Mike,
I find it very difficult to actually get business stakeholders in many clients to even agree on the value of “nonfunctionals”, a lot of these constraints seem to come from technical stakeholders like enterprise architects and technology owners.
In your view is it okay to add a story like
“as an architect, I want the system to be hosted using WebSphere application server so that I can simplify the management of my enterprise portfolio”
Assuming that the architect is not a team member…
Jeff
Hi Jeff–
Sure. I’ll give you another example I heard a bit ago. The CTO happened to walk by when the team was planning. He stopped in for a listen. The team was discussing whether to build a new application by connecting to an existing orders database or by replicating that database to a local one every night at midnight. The CTO settled it by adding a story: “As the CTO, I want you to use the existing orders database so that we don’t end up supporting an additional database for 20 years just because it seems easier for the next few months.”
Others could be about “use C#” or “comply with the company coding standard.” Examples like these are why I really prefer the word “constraint” over “non-functional requirement.”
I like your (Mike’s) reply to Johnstok. To me, a ‘non-functional requirement’ often translates to the developers as ‘create an automated test that proves that the system will achieve this requirement’. Things like load testing and performance are vital things to add to the project and need to be introduced at the correct point (as decided by the PO and CTO).
As the delivered feature is an automated test, it should never go away and hence is not forgotten.
Return to the old ages. From one of the old boy of agile (when there were no such a word as Agile): Tom Gilb (www.gilb.com) Has a few very interesting book about agile project management (not called agile).
So this Tom Gilb has a very strong opinion about how to handle such a requirements and give great hints how to measure these.
Tom does, indeed, have excellent advice on non-functional requirements (as well as every other type of requirement). I’d encourage everyone to read his Competitive Engineering book as well as his Principles of Software Engineering Management book. By the way, my company is named after his “Mountain Goat” principle in that book:
Take one step at a time up the slippery mountainside, and make absolutely sure that each hoof is on solid ground before you take the next step.
When I named the company back in 1992 this was about incremental development (“the next step”) and making sure each increment was what we’d call “potentially shippable” today. Tom was indeed the original agilist in my mind.
I had the honor of having dinner with him last month for the first time. He and his equally brilliant son, Kai, through a challenge at me that I haven’t met yet. I’m planning to blog about it this weekend to see if anyone here can help me! Stay tuned.
I wonder if I can meet the challenge these youngsters throw at us Mike!
– awaiting your next blog
Tom
I think you will find that ‘constraints’ is an unfortunate categorization for ‘non-functional’ requirements.
We have some agreement that the term non-functional requirement is not a good one. I seriously suggest that the many people who use it have not yet thought very deeply about requirements. I detest it and its use.
My books, that Mike refers to above go into some depth on this matter for those who wish to go deeper than this reply can do.
I used to be confused myself, before I began to work out the terminology deeply.
One way to go deep is to access the many requirements concepts in my Concept Glossary
http://www.gilb.com/tiki-download_file.php?fileId=25
I used to think that ‘all requirements constrained’ (even function requirements). All requirements constrain our other choices (design, architecture, timing and more) but it is still not useful to call all non-function requirements ‘constraints’.
I got the necessary insight in a flash once, when I realized that some requirements are ‘primarily intended’ to constrain. And some requirements are not primarily intended to constrain.
They might just do so incidentally. They might incidentally inspire, seem stupid, waste resources, be unnecessary, and they might incidentally have many secondary unintended side effects. But I would not classify all non-function requirements as ‘inspirers’, ‘stupid’, or ‘unnecessary’ because of these side effects. By the way non-functional (the -al) is bad grammar!
There are many interesting types of requirements that are not function requirements. See the Concept Glossary, under ‘Requirement’ for a chart of them. The most interesting requirement types from my viewpoint is what I call ‘quality’ requirements. Quality requirements describe ‘how well’ a function needs to be done (as Mike points out, mostly ‘ilities’).
But, and this is true of all scalar requirements, there are two basic scalar levels of requirement, and both can be applied simultaneously. I call these two classes ‘targets’ (levels of quality we might value reaching), and ‘constraints’ (levels of quality we would value not falling below).
A simple example in my Planguage:
Maintainability:
Type: Quality Requirement.
Scope: All software in products, or their support systems, that we provide to customers.
Scale: Mean Time to Completely Fix a Bug from its Existence is ascertainable.
——– Here are 2 different constraint requirements —-
Fail [2010, UK] 24 hours
Catastrophe [2009, Europe] 1 week
——— Here are 2 different Target Requirements
Goal [2011, Worldwide, Games Sector Products] 1 hour
Stretch [2013, Worldwide] 20 minutes.
The above concepts are explained in the Concept Glossary, but most of you can guess their basic meanings. Concepts like ‘Goal’ have a defined set of attributes such as: must be technically feasible, within budget, prioritized etc. ‘Stretch’, for example, does not have such requirements!
‘Fail’ and ‘Catastrophe’ level requirements are primarily intended to set clear lower limits. But ‘Fail’ simply means that ‘below that constraint level things are unpleasant’ (like ‘difficult to breathe’) but recoverable. ‘Catastrophe’ is a constraint that signals disaster, possibly irrecoverable (suffocation).
This is enough to hint at the potential, useful, distinctions in requirements. Hopefully the astute reader is beginning to see what we cannot simple declare all non-functions to be ‘constraints’. It is not logically true or useful!
more at the website gilb.com
Tom
I tried this with a team a long time ago (see http://tinyurl.com/agmqrj) and it was really successful.
As you say in your post, the “as a, I want, so that” format is an excellent way to communicate the constraint in terms delivery teams are intimate with. On top of this, I found that the “as proven by” clauses were the key to flexible and pragmatic adoption across every project – without having to write them explicitly for every feature.
IHMO giving people standards to meet and philosophies to work by always beats verbose prescription!
A great article for me. this is very useful for someone to learn about agile.the information is in a simple way with examples. as students we need these type of articles. thanks a lot.