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.google.com) 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.
This is indeed a great blogpost.
You wrote to the comment of Mike Cottmeyer that you would write a blogpost for his questions. Sadly I couldn’t find it. We are having the exact same problem.
I’ve browsed around on the web a little and haven’t found the best solution for us yet.
I really like the idea to write these requirements up as stories. What we are thinking to do now is to have them in focus during sprint planning and sprint execution. Part of the constraints are set as acceptance criteria to stories under development, part of the stories must be in scope at all time (for instance Usability requirements), part of the constraints we want to address as a story during a certain sprint (performance and security requirements) because we want those stories validated by automated tests. We want to schedule certain non functional validation sprints after a couple of sprints that have a functional focus (hence delivering business value is important to us) to validate these characterstics when we have delivered some functionality. Personally I think this is not the best solution but we are at the start of our new product development project and for the first phase this will work. Any thoughts and experiences are very appreciated.
Hi Wim–
I’m glad you like the post. I’m sorry I haven’t written a post yet about scheduling non-functional stories into a sprint. When I do, my answer will be that there are really two costs to a non-functional requirement (“constraint”):
Performance testing is a good example. There’s an initial cost of achieving the right performance level. Then there’s a cost to maintaining that level of performance.
Thanks for a great blog Mike and this topic especially. I have a question though, and it may be a stupid one, but I’m just trying to clarify some confusion I’m having when writing a PRD.
If a “Non-Functional Requirement” is considered a “Constraint” then is it possible for the “Non-Functional Requirement” to also be a “Constraint” relative to a “Functional Requirement”?
Thanks
Hi Edgar–
I’m not sure I follow your question. “Non-functional requirement” and “constraint” are really two terms for the same thing. I would use them in a sentence as “A non-functional requirement is a constraint on how the system is developed.” For example, someone saying we need to support 50,000 concurrent users is giving us a constraint: “Design the system however you want but make sure it supports 50,000 concurrent users.” So in that sense a constraint applies to all functional requirements. I think of these also as “cross-cutting” requirements—the constraint cuts across all other requirements of the system.
The NFO covered here are traditional one. With progress in technology and understanding of software capabilities and engineering new breed of NFO has emerged. I have tried listing some of the contemporary NFO at my blog (http://architecture-soa-bpm-eai.blogspot.com/2010/10/contemporary-non-function-requirements.html)
In my past, Mike’s steps above:
> 1. the cost of initially complying with the constraint. This can easily be scheduled into a sprint when the team decides (with their product owner) to do so.
> 2. an ongoing cost of complying with the constraint. I think of this like a tax.
Translate into:
1. A story in this sprint (to come into compliance with the constraint)
2. In the same sprint the compliance story is implemented, the constraint is added to the definition of done for all future stories/sprints.
Requirements are often thought of as statements, but they are decisions. Each and every requirement is a decision whether functional or non-functional. In game theory, the preferences of the stakeholders reflect the individual decisions of each stakeholder. you can meet their expectations or persuade them to change their expectations.
Constraints, for myself, originate in the implementation environment: in the dev organization’s policies, tools, and approaches, in the APIs, in the databases, in all the things that would be there regardless of what we were coding–in the carrier. Non-functional requirements originate in requirements elicitation. The difference in origin is significant when you consider that all requirements face off as an opposing force against those constraints. Design is a matter of aligning these forces or creating and maintaining a surface pushed from the requirements side and the media’s constraint side. This definition holds for all designers regardless of what they are designing and what media they are realizing their designs in.
The tax you are talking about is one similar to the API tax. When we use an API, we get stuck following the upgrades to that API. I’ve worked in places where one programmer was assigned that API. That developer was the tax payment.
Try writing that user story from the point of view of doing, rather than wanting. The value of software is in the doing, not the fulfilling of wants. When a response time requirement is not met, I end up multitasking. In the sense of the attention economy, allowing attention to shift beyond your application is a huge loser.
Some of your non-functional requirements are not the responsibility of dev. Some of them describe “how”s, rather than “what”s. The database requirement needs its own persona, as do other architectural issues.
Jeff, that architect would be a persona. As such, that persona would have some user stories.
Considering an NFR to be a constraint like the constraints brought into our application via an API, and the notion that we expand our reach across the category of a given API by using an adapter pattern, how could we treat NFRs via design patterns like an adapter pattern. Typically, you change your algorithm, so you would use an interface definition. Are there other approaches? I liked the “cross-cutting concerns” approach mentioned that Mike mentioned.
That a NFR is never done implies a process, rather than a project.
I had the gilb epiphany on NFR’s many years ago and it has been a key guiding framework since then. I am now working to operationalise this approach into a practical process that integrates User Centred Design, product-level User Stories and agile development with a more traditional enterprise governance environment.
my interpretation of Gilb’s work is that NFR’s are a set of scalar ranges along one or more dimensions that are important to your particular product space.
Btw, Tom has elaborated a very well defined set of quality scales that are applicable to most software systems into a nicely self-contained and complete hierarchy, but I haven’t worked in many teams that can “get” that level of sophistication
Nonetheless there will be a finite set of quality dimensions that make sense to your application area (even though they may be less perfectly integrated with each other than Tom’s hierarchy).
it’s important to realise that (except in rare cases) these values are on a continuum and not isolated discrete values which are interpreted as “good” or “bad”.
For example the dimension of response time to a user action. You may define 3 secs as minimum acceptable and 5 secs as full production target. That sense of absolutism might be fine for the system owner, but for an end user in a population you are going to have a large range of groups who have very different levels of sensitivity to this quality dimension. You might capture 100% of your target market at 3 secs and 95 % at 5 secs, but there will be a large percentage for whom 8 or 10 secs is acceptable, and another group for whom 15 secs is ok etc.
So, the aggregate effect of defining multiple quality dimensions is to define an ecosystem in which your target users will live: quantitative ranges of availability, performance, usability and the sub-dimensional quality scales that exist within each of these. this is not a binary scenario (except in rare cases) but a set of statistical aggregates that will affect your market take up.
at this level it is perfect for Business Case development: e.g. if you build it with 3secs response time and 6 9′s availability, it will cost you $30m and you’ll capture 20% of the market. But if you build it with 3 secs response time and 95% availability, it’ll cost you $10m and you’ll capture 15% of the market. Only your business guys can tell you whether the extra $20m is worth the extra 5%, and so forth.
as you start to set your first target and minimum acceptable values on these dimensions, you focus the team’s attention on this ecosystem; initially indirectly (I dare myself to use the word “ecosystem” in the first workshop – not)
In a long-range product development program it’s important to realise that the target, minimum acceptable, stretch and ideal values on these scales will change, as you learn more about the market and more about the technology.
It is absolutely critical to lay down the initial scales and target levels early to start the process of focusing your attention on what qualities are valued in your target user population, and developing the team vocabulary to describe and analyse them.
In recent days I’ve had some fairly visceral responses to the suggestion that we start to establish these frameworks: essentially “how can I set a response time when I don’t even know what hardware is being used to host the application, or where it will be located”.
as (I think) Tom Gilb said in one of his books (and i’m going completely from memory here): “I can implement any functional requirement you ask as long as you relax sufficiently the non-functional requirements with which i must comply when doing so” (or words to that effect).
Unfortunately it’s all too easy for teams to have a mental “fingers crossed” approach when confronting these qualities: “well of course I can provide *instant* response as long as *instant* means 12 seconds” or “…if we disregard the cellular network latency” … etc.
if you don’t start trying to define the target ecosystem quantitatively and explicitly, you will never get full alignment on what you are trying to define and build.
on the specifics of “how to do it” my 10c worth is as follows:
1) i think it depends on your team’s level of sophistication and experience whether you start with a “public” and explicitly defined NFR framework at the start, or build it up from the user stories (see below), but you must always start with a private framework in place: one that you understand intimately and can act as your assurance framework.
2) I think starting with the phrasing of these NFR’s in the user stories (as per Mike’s old post above) with a user’s target value is a good one: “as a user, I want to see my news stories appear within 10 seconds so that my security lockout doesn’t invoke due to non-activity”. This gets the scale onto the agenda and we can focus on the benefit(s). not every user story has to have this but you are trying to expose the targets that are valued by your key users.
3) once you have built up a set of stories that have value descriptors, you can start to extract them and integrate them into an NFR framework – refining the definitions of each of the values and consolidating, where appropriate, multiple descriptions of the same thing.
4) at this stage, if you haven’t had your full framework public, this is the time to use your framework to make sure you aren’t missing anything.
5) finally (in terms of this stage) you attack the dimensions to explore the continumum of values and set your various points: minimum acceptable, target (on date) etc.
there is much furhter refinement that comes later when you have to start costing these, but the idea is to carry these scales all the way through your sprints and testing (at which time you start recording actual values on dates) and then into your early stage deployments, user testing, etc.
Hi Adam–
Thanks for sharing this. I agree with much of what you’ve written, in particular that most thresholds do not need to be viewed as absolutes. We don’t lose all users/customers if performance is 4 seconds instead of 3. Incidentally, “Mountain Goat Software” is named after the “Mountain Goat Principle” on p. 99 of Tom Gilb’s “Principles of Software Engineering Management” book, which is one of my favorites.
According to my feeling, these non-functional requirements fits into Acceptance tests rather than user stories itself.
We can write the above non-functional requirements as Test like
“Product should run on all windows from windows 95″ is similar to “Test paying with MasterCard (Pass)” in the Job posting scenario in “Applied USer stories”
I do not find any difference there. My knowledge in agile may be low, but I dont get the real difference here.
Hi Prasantha–
Yes, these could be written as tests. Any user story could be rewritten as a test–users can log in would be a rewrite of “as a user, I must login before accessing parts of the application.”
Thanks Mike. When I write a user story, I always get the feeling that this is something to be developed during the project. But these constraints even though written as separate user stories are nothing to do with developments. Rather they are for the team so that you do not violate them while you develop other stories during the project.
For example “•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.”. There’s no development involved, but a reminder for the team.
Am I correct in the interpretation of constraints? So, where should we place these constraints? I dont feel it should be in the Backlog.
Hi Prasantha-
In general, I do think constraints include development work–a performance story, a usability story, etc. You’re correct about the “As the CTO, I want the system to use the existing orders database” but that is not the most common type of constraint or non-functional requirement.
I tend to hang constraints on the wall in the team room or put them on a project home page where they remain visible. Many do, however, start on the product backlog because there is work to be done. This is covered in more detail in the Succeeding with Agile book, which talks about the two costs involved with nonfunctionals–the cost of initial compliance and the ongoing cost of supporting a constraint, which is really best thought of as something like a tax.
Thanks so much Mike.
Describing non-functional requirements often means there is no ‘wetware’ as the consumer. The examples given in the blog neatly avoid the issue altogether by coming back to how a physical person (wetware) is affected; noble but very contrived.
The solution for me is to personify the consumer of the non-functional system. Let us say we have a SOAP interface call “Sudsey” that is consumed by another service called ‘MyCoolConsumer’, I would personify the consuming client by using its name as if it were ‘wetware’. eg. “As “MyCoolConsumer” I need to be able to securely obtain information from Sudsey.
It is perfectly fine to use the name of the consumer (MyCoolConsumer) as it is a role with needs. Its needs are much easier to scope with a User Story than any real-world person
Further, this method does not break the Scrum-way and neatly prevents arguments from some of my more Luddite colleagues.
Comments?
Hi Aeomer–
I think that writing stories in first-person for non-functional requirements is fine. I see programmers talk this way all the time, “OK, if I’m the loan approval system and you pass me bad data, I should first….” So writing a story in a similar way has always seemed fine to me.
Hi Mike,
Very very informative and interesting comments. Could the NFR also be taken as part of Condition of Satisfaction as for each functional US we could then check as part of Done or Demo if these are also met or not.
Hi Sonali–
Yes, NFRs can be viewed as part of the definition of done. That’s a good point I often fail to mention so thanks. I usually start by thinking of a non-functional as it’s own user story. Once we do that story and “accept” the non-functional requirement, it becomes part of the definition of done and is applied to every story from then on.
Hi Mike,
In terms of format, I like to express NFRs in a format other than the User Story to distinguish them from Backlog items. I don’t include them in the backlog. Rather, they are reviewed as new features are built and part of the “Definition of Done” for a potentially shippable increment and/or release.
In terms of format, I’ve worked with the below ones but have a preference for #2:
(1) Traditional (Old School) Format — a statement.
E.g., New third party content must be integrated and available in search results within one hour
(2) Traditional Format with Value to the User — A statement with the value stated separately.
E.g., New third party content must be integrated and available in search results within one hour. Value: The end user can receive fresh search results using our search engine
(3) User Story Format — self-explanatory.
E.g., As a subscriber, I can receive fresh search results so that I don’t have to go to other sites when I need the latest content
Format 2 contains the same information as a User Story (provided that the user is clearly defined in the value statement). However, the format more strongly suggests that it isn’t a feature on the backlog which can be discarded once the conditions of satisfaction are met. Instead, it is persistent.
Thoughts?
Drew
Hi Drew-
I don’t have any objections to these formats. I used to do non-functionals more like this but for the last few years I’ve written them more often as user stories. I don’t think doing so adds a ton of value (although it does for functional stories). But, I wrote this post to show that it can be done as a lot of people think it can’t. And, I do find that many teams prefer all their requirements to be written in a consistent manner.