Concise requirements give your team a useful, easy to read and easy to change understanding of what must be done. Great requirements exist to do three things:
- Identify the problems that need to be solved.
- Explain why those problems are worth solving.
- Define when those problems are solved.
Concise Requirements – Revisiting
In the three years since we last looked at Writing Concise Requirements from the Big Ten Rules of Writing Requirements, the iPod evolved to give us a better experience. Let’s see if we can do the same with the topic of brevity in requirements. The size of our community here has grown ten-fold, and the people who were here back then have grown just as much. It makes sense to look at this again.
Writing concise requirements is not just minimizing the number of words you use. Writing concise requirements is presenting the most important information in the easiest format for your audience to consume.
Concise Requirements Identify the Problems That Need to be Solved
Ultimately, requirements are the problems that we choose to solve. A concise requirements artifact (formal document, index card, photo of a whiteboard, whatever) is one that has the highest signal-to-noise ratio possible. You’re maximizing the amount of communication, and minimizing the cost of communicating.
You want your requirements document to read like the lines, not the points. If the line (the signal) is what you really want, and you communicate a big pile of points (the signal, hidden in the noise), you run the very real risk that your audience will misinterpret the signal.
User stories provide the best example of clarity that comes from conciseness. The format you should use, based on Mike Cohn’s great book, User Stories Applied, is
As a [role], I want to [do something] [with some frequency] so that I can/will [achieve some goal]
The user story is not always the right communication format – it depends on what problems you’re solving, and who is on your team. Sometimes, use cases work better than user stories. Conciseness is important for use cases too. Start with a good use case name.
Concise Requirements Explain Why Those Problems Are Worth Solving
Last week’s article on Valuable Requirements focused on why particular problems should be solved. Your focus should be on value, and that article discussed five ways to assure that your requirements are valuable. One of the techniques, the use of an Ishikawa diagram, provides a method for identifying the root causes of problems.
Imagine that you have a collection of user stories, representing problems to be solved for your users. You need a way to demonstrate why this user story should be implemented and why that one shouldn’t. You can often use the Ishikawa diagram in the same way. A particular goal is achieved when a user is able to do something. Perhaps several somethings are required. The point is that you can use the Ishikawa to drive home the point – if this set of user stories are all implemented, then this goal will be achieved.
There are two reasons this is important – first, you’re providing context for your team. They understand why they are doing something. Second, you can make changes easily, because you can see the impact of those changes. By understanding the cause-and-effect relationships between problems and their values (user stories and their goals), you can see the impact of changing one or the other.
Concise Requirements Define When Those Problems Are Solved
Clarity is the goal of conciseness. It isn’t enough to say “work on this.” It’s important to know why you’re working on it, but that still isn’t enough. You have to know when you’re done. When you’re defining problems to be solved (and therefore solutions), you must also define the measures by which the solution will be judged.
A measurement of success for “Cost of Operation is Too High” might be “reduce costs of operation by 10%.” This gives you a testable criteria for knowing when that problem has been sufficiently solved. Sticking with the Ishikawa, you can also map out the strategy for achieving that lofty goal. You can say that the goal is to reduce fuel expenses by 20%, reduce cost of maintenance by 5%, and reduce payments by 15%. This process continues – a 20% reduction in fuel spend requires that you operate with your tires within 5% of nominal pressure, and that you reduce the aerodynamic drag coefficient by 7% (or whatever).
This gives you clarity in your objectives.
User stories, when combined with user acceptance criteria, provide that last connection of testability that lets your team know when they are done.
There aren’t many things more frustrating to a development team than having them solve the wrong problems. One of those things might be having their solution be rejected because it isn’t enough. Writing acceptance criteria clearly and concisely lets the team know exactly when they can move on to the next problem.
Providing a crisp understanding of acceptance criteria also facilitates iterative development. One challenge teams always face is making improvements that fit within the timebox of a given iteration. Imagine a user story with 4 acceptance criteria, where the story is too big to complete in one sprint. When talking with your development team, you may find that the story is too big because satisfying all of the acceptance criteria is too big. This is where many teams miss an opportunity – by defining all of the acceptance criteria that are believed to be needed eventually and requiring that they all be implemented now. One of those criteria is going to be more important than the others. Implement the story such that is satisfies the most important criteria (timeboxing) now, and rewrite or enhance it to meet the additional criteria later.
Conclusion
Software Product Success depends not only on identifying the “right stuff” to build, but on making sure the team builds it and builds it right.
Concise requirements improve your ability to communicate with your team, thereby improving their ability to build the right stuff right.
With this latest post, I sense we’re coming close to converging on a number of issues!
First, requirements are about stating the problems to be solved, in measurable terms that state the conditions that must exist to know that they are solved. I agree that giving the context of why they are worth solving is also important.
Second, user stories with acceptance criteria are a great way of expressing requirements, and they can be similar to black box use cases.
Third, relaxing the acceptance criteria is an important (and often neglected) way of splitting a user story across multiple iterations. The concept is very similar to employing constraint-based use case versions.
One thing with which I’ve observed Scrum practitioners struggling is acceptance criteria. Rather than expressing nonfunctional requirements in acceptance criteria, it seems that most Scrum practitioners embed design assumptions in them.
Hey Roger,
Yeah, we’re converging :). Or we’re both getting pragmatic as we age, and acknowledging that while we both push on a couple ideological levers, our realistic goals are to move the bar in the right direction.
Design / implementation / requirements – I think teams will always struggle with that. An intrinsic challenge is that one person’s “how” is another person’s “why” so even when people agree conceptually, the language can still be ambiguous (hmmm. maybe I should continue on the ‘revisiting’ thread).
On the requirements/design distinction: yes, there will always be potential for quibbling over the existence of design assumptions in specifications. However, realistically, the issue hasn’t been over such subtleties. The debate has been more fundamental, such as whether use case steps and user interface specifications are inherently design, and whether the terminology is often contradictory (e.g. requirements as the output of interaction design activities).
This is the core of any requirement for any development methodology.
Look at your requirements and see how many describe the 3 points in the article
1. Identify the problems that need to be solved.
2. Explain why those problems are worth solving.
3. Define when those problems are solved.
I bet many will be surprised.
Another note. It is the “so that” piece that is the critical one. When you describe a problem, always try to focus to the “so that”. Ask your Product Manager or Developer, or Designer. Ask your noisy customer or your account manager. If that is hard to elaborate, it’s probably a problem that needs to be revisited in some way. If the “so that” is immediately clear and even quantifiable, bingo!
Thanks @Donato and welcome to Tyner Blain!
The “so that…” is the piece of the puzzle that is most in our (product management, business analysis, requirements management) area of responsibility. Great callout. The other areas are very important to informing other members of the team, so I would not reduce the big-picture emphasis on them. But you’re right – “so that…” is the one that sets (and validates) direction.
Much cheering and cringing in this article…
“Concise Requirements…” — Yeah for concise!
“User stories provide the best example of clarity that comes from conciseness. The format you should use, based on Mike Cohn’s great book, User Stories Applied…” — Yeah! I love and promote this template often.
“Identify the problems that need to be solved.” — Ouch. Problems have to be written and communicated outside the record of the requirements. Problem statements are too hard to write and be understood within the context of the requirement. This especially conflicts with the user story template. User stories typically articulate how someone works, how they want to work or how they will work and the template has a solution smell to it which distracts from the problem.
“problems and their values (user stories and their goals)” — Ouch. This is very misleading.
In general I agree with the whole article, but the context of describing the problem concept within the notion of a requirement is a bit troublesome for me.
Stewart
But Stewart, the problem is the requirement. Or, more precisely, the requirement is a concise formulation of the minimum conditions that must exist to know that the problem has been solved. Anything more, and we are venturing into design specifications.
Hey Stewart and Roger!
I agree with Roger – the problems you (choose to) solve are the requirements. That’s what goes in the strategy/vision/roadmap. I suspect Stewart is saying “don’t bury those requirements” down inside the specification – I agree with that too. But definitely reference the problems from within the spec. There should be traceability from each user story (or use case, or non-functional requirement or whatever) back to the problem (requirement) that drives the need for that capability (also a requirement).
It needs to be clear to the implementation team why any particular activity they are going to perform is required. It needs to be clear to the product owner why any item in the team’s backlog is there, so that the implementation team can make informed decisions when changing that backlog. The context why any of that work is important needs to be clear to the entire team. That establishes the framework for making changes at any level (choosing a different market, devising a different strategy for attacking that market, changing the timing of executing a strategy, or infusing new ideas regarding ways to execute that strategy).
@Roger: I completely agree with your definition of a requirement. I am merely suggesting that I shouldn’t have to infer from the requirements what the problem is. Your definition of what a requirement is (again I agree with this) tells me the conditions that must exist to know that the problem has been solved. I want something that specifically tells me what the problem is first. Simply put, I want to see a problem statement and its requirements.
@Scott: I am not challenging the value of communicating the problem (I might be the biggest proponent of them!), but advocating that you take the time to understand exactly what the problem (write it down) before you start with the conditions to solve that problem (i.e. requirements).
Again, and I think this is worth repeating, in general I agree with the article (another share-able classic for Tyner Blain). I just don’t want to see the “problem definition” step mixed in with “requirement definition” step. Hence my cringe.
@Stewart – Hmmm.
I think of the problem statement as something like [target customers in target market] are spending 10% of revenue on [solving some problem of theirs].
I then think of the requirement as something like: Provide a solution that cuts the cost of [solving that problem][for customers in that market] by 25%.
You can establish a measure of success – did customers reduce from 10% of revenue to 7.5% of revenue spent on [solving their problem]?
That isn’t changing the level of abstraction, just a distinction in language where ‘problem statement’ is an understanding of the problems our customers face, and ‘requirement’ is a reflection of the strategic decision to address them (now).
Stewart, by stating the conditions that must exist to know that a problem has been solved (or avoided), a product manager states what the problem is.
If the problem is that it takes more than four minutes for a cashier to process a transaction, then the requirement is that it takes four minutes or less for a cashier to process a transaction.
We might express this requirement as a Process Transaction use case combined with preconditions and postconditions that specify the duration constraint. Or we might express this requirement as a Process a Transaction user story with acceptance criteria that specify the duration constraint.
Now, these means of expressing the requirement are not concise. But they are equivalent to problem statements.
Scott, it appears you and I have some remaining divergence on the relationship between problems and requirements.
You give as an example of a problem statement:
“[T]arget customers in target market] are spending 10% of revenue on [solving some problem of theirs].”
I guess you could characterize the “[problem of theirs]” part as the the primary problem and the effect on revenue as a higher-level problem (a financial context) that results from it.
We have to choose which level of problem we are going to solve. I doubt we’d want to be accountable for solving the higher-level problem, as some of its causes are likely outside of our control.
From your problem statement, it’s not clear what level of problem you want to solve. But then your requirement suggests that you have chosen to solve the higher-level revenue problem, not the primary problem that causes it.
Whatever level of problem we choose to solve, in my opinion the requirement is nothing more than the logical inverse of it. Thus, if you choose “spending 10% or more of revenue” as the problem, then “spending less than 10% of revenue” is the requirement. Surely the problem has been solved or avoided if the condition that you stated as the problem no longer exists.
@Roger:
Let me try writing it another way – I suspect we agree, and are just ‘talking past each other’.
There’s a trend among [my target customers in my target market], that they are spending ~10% of their revenue on understanding their relationships with their customers and prospects. My target customers have an abstract goal of “be more profitable.” To your point, we aren’t signing up to solve the abstract “be more profitable” problem, because we have a strategic focus as a company on providing solutions “in the CRM space.”
We’ve identified (because we know the domain) that companies spending 10% of revenue on understanding relationships [solving some problem of theirs] have an opportunity to spend much less than 10%.
So we almost entirely agree. We’re only differing in that I find it to be important to call out the “how much” element – because that is (1) key to our market viability, because it defines how much our product would be worth to our customers, and (2) it defines clearly when we are “done” and ready to go to market.
@Cauvin,
On “… are use case steps and user interface specifications inherently design, or … terminology contraditory?”, yes, you can do it that way. I was shocked to find that requirements are theory driven. I wasn’t as shocked to find that integration applications negotiate away meaning, hence the terminology problem. Neither of these two things works in a long-term market adoption situation. Going directly to Saas and dying young will let you engage in those practices.
On problem, the customer spends time solving the problem, aka engaging in some ritual, but the programmer who doesn’t engage in the problem as a user will solve the problem in their own way, not in the way the user would solve the problem. So much for listening to the customer, or eliciting requirements from the user. Fundamentally, we need to preserve the user’s meanings and rituals.
You’re right, Scott. We’re even closer than I thought in both our semantics and our substance.
A few observations.
First, there is no disagreement over the idea that we need to quantify the the extent of the problem and the extent to which we are promising to solve it. Stating least stringent conditions is a core part of expressing requirements.
Second, I am skeptical that we would want to take on the requirement “reduce the cost [for our customers] of understanding their customers by 25%”. In our market research and requirements elicitation, we’d want to probe why it costs too much to understand customers. Those reasons might be the problems we’d choose to solve.
Third, there are subtle semantic implications to your quantifying of the problem and the requirement. Which is really the problem:
1. Spending 10% of revenue.
2. Spending more than 7.5% of revenue (knowing that the actual amount is 10%).
3. Spending revenue (no matter what the amount, but we want to reduce it to the extent feasible).
You seem to be stating that 1 is the problem, and the inverse of 2 is the requirement. I contend that all three are problems, but that 2 is the problem we are choosing to solve, and the inverse of 2 is the requirement.
@Roger: I think we fundamentally disagree on what a problem is. Not to pick specifically on this example, but “it takes more than four minutes for a cashier to process a transaction” is not the root problem. What you have done is written a requirement for A problem but likely not THE problem. And typically what most people do is provide a solution for A problem and not THE problem. This was the point of Seth’s post (http://bit.ly/qRsHT) yesterday. Problem definition and requirement definition have to be two distinct steps and the language of both outputs are different, but they go hand-in-hand and at the end neither can exist without the other.
@Scott: In comment #11, I agree with this, but I also agree with Roger. the 10% is the impact, not the problem. On top of that though, I agree it is very important to understand and communicate the impact for all the reasons you stated in comment #14.
Thanks everyone very much for the great discussion!
I’ve been thinking about this for a couple days, and I think at the end of the day, 3 is the problem – companies are spending “any money at all” to understand their customers. But that means the real problem is that our customers need to understand their customers. Some of our potential customers will have no solution in place for that problem. Others will have solutions in place (home grown or purchased). We have competition that solves this problem. Our customers have to choose how they want to address this problem – our solution, someone else’s, or their own (or continue to have no solution).
The cost of our solution is probably relevant to our customers and prospects when making purchasing decisions, as would be other elements/attributes of our solution and other solutions. As part of our market analysis, we should estimate the number of potential customers at given price points. Included in developing that estimate is an understanding of current costs and associated potential savings (at each price point). Or a continuous function of “value vs. price” if discrete points don’t make sense. Depending on how we want to position and penetrate the market, we can pick one or more price points versus that model.
From a business standpoint, we should have a target profitability model – at price point X, we can spend Y to develop the solution, and Z as ‘cost of sales.’ I’m oversimplifying, but basically, there’s an amount we can spend to create, maintain, and sell our product and meet our corporate profitability objectives. We may even choose to operate at a loss, for other reasons (like penetrating the market).
From that point, we should be balancing our sales / customer sat / etc versus the model, and our costs versus the model. Any variance analysis (didn’t sell as much as we thought it would, cost much less than we thought, etc) should drive both an assessment of the model’s accuracy and of our performance in defining the right product, as well as our execution in creating it.
Is there a better strategic framework for driving this analysis than saying the requirements is “25% cost reduction for our customers…”? Yeah, probably. We want to say “provide a solution that has X cost for our customers, while yielding Y profit for us.”
Stewart, I think where we have a disconnect is that you’re implying we have to address the “absolute” root problem. I maintain that there is a chain of problems, and that we must as product managers intentionally stop short of the root and select a problem further down the chain.
I wrote about the issue of problem chains a few years ago. We will never comprehensively address a core need of human beings (e.g. happiness).
What we do as product managers is identify problems further down the chain that are obstacles to satisfaction of core needs. We strive to find problems that are as high up the chain as possible, but only insofar as we can confidently promise to solve them. Otherwise, all of our problem statements and requirements would focus on health, sex, safety, and social acceptance.
Well said Roger! And, an excellent lesson. Perhaps this is why Toyota asks why five times and not infinite times.
Great discussion thread, all!
now, once we do have the ‘big view’ — just enough to be sure we’re solving the right problem, have a vision and business case, market understanding etc. — i want to get back to a key point in Scott’s article case around ‘concise requirements’.
for me in working with agile teams, a key is having those acceptance criteria. so yea, we want to be concise, but also unambiguous (clear) with each of these small, tamped down requirements. the acceptance criteria help us do that.
~ ellen