Writing Verifiable Requirements should be a rule that does not need to be written.  Everyone reading this has seen or created requirements that can not be verified.  The primary reason for writing requirements is to communicate to the team what they need to accomplish.  If you can’t verify that what the team delivered is acceptable, neither can the team.  This may be the most obvious of the rules of writing requirements – but it is ignored every day.

Verifiable Requirements – Revisiting

In 2006, I first looked at how and why writing verifiable requirements is important - as part of the ongoing series on the rules of writing good requirements.  The focus of that article was on testability, as is this one.  When visiting verifiability again, however, I will add that not only must specifications be objectively measurable, but so must goals be written so that you can identify when a solution has met the objectives that justified its creation.

Directly Verifiable Requirements

Most of the requirements we come across can be directly verified.  The only problem with these requirements is that they lack specificity.  The following example is almost verifiable, and only needs a little help:

• The web site must make it easier for users who use site search to find the products they want to buy.

This requirement presents the challenge of resolving the ambiguity of the requirement. This lack of specificity prevents the requirement from being verifiable.  You have to identify how much easier the site search process must become for users.  Findability is a more is better characteristic in the Kano Analysis model for defining requirements.

You have to acknowledge that making it easier to find what you’re looking for is better for users than making it harder – there is an upward slope to the function.  However, there are also diminishing returns.

[larger image]

• A search that includes “the perfect item” is massively better than a search that does not include what you are looking for.
• A search that includes the perfect item on the first page of results is significantly better than one that returns the perfect item on the second page of results.
• A search that includes the perfect item as the first result is only marginally better than a search that returns that perfect item as the second or third result.

Improving findability as articulated above, from a user perspective, manifests in value to your company in two ways: immediate revenue impact and indirect revenue impact.

The immediate impact can be measured in terms of increases in commerce.  The indirect impact results from improving the user experience.  These improvements in experience result in increased word of mouth, as users altruistically encourage others to visit your website, and also result in an increase in satisfaction causing users to return to your site more frequently and make more purchases from you.

You can measure these impacts in terms of

• Conversion percentage (percentage of people who search and then purchase the products found in the results)
• Revenue attributed to users who search (an absolute measurement of purchases of products found via search)
• Site traffic levels (the number of people that visit your site over time)
• Visitor-recency statistics (the amount of time that elapses between return visits for returning visitors)

Conversion percentage, for users who search, normalized against users who do not search, is the most isolated (from other variables and noise) and fastest responding (as a delayed measurement of impact) measurement of the value of making it “easier” for users to search for the products they want to buy.

Your team will design different approaches to achieving these improvements.  You have to estimate both the cost and the potential benefit of each approach.  Balancing cost estimates with potential benefits will yield the ideal requirement – perhaps a 10% improvement.  [Note: I've collapsed at least another article's worth of balancing cost versus benefit, and multiple articles of "understanding and measuring site search" into one paragraph here, in hopes of staying on task with writing verifiable requirements.]

Rewriting the requirement as follows makes the requirement verifiable:

• Before: “The web site must make it easier for users who use site search to find the products they want to buy.”
• After: “Users who search on the site will be at least 10% more successful at finding the products they want to buy when using site search.”

Impossible to Verify Requirements

Often, stakeholders will present us with requirements that are impossible to verify (as requested).

• The home page needs to load fast.

At first blush, this looks just like the previous requirement (easier search is similar to faster page load).  You can use the same techniques to determine a measurable “requirement” like “the home page needs to load in under 1 second.”  However, that’s not a good requirement, because it is not an implicitly valuable requirement.  This statement provides no insight into why a fast-loading home page might be valuable to a particular user or why it would be valuable to the company.

To address this issue, you have to meet with the stakeholder(s) and understand the actual underlying requirements.  You will ask why, determine motivations and underlying problems, and apply active listening skills to discover the underlying requirement.

The problem is that the statement, “the home page needs to load fast” is a specification.  In Requirements Documents – One Man’s Trash…, I first used the following diagram to show how different people in the process of designing software view their piece of providing a solution.

A developer may receive a spec – “home page must load in under 5 seconds” and feel like the why component is perfectly well defined – it is a matter of context and perspective.  Another way to think about this is that the problem is with the problem statement.

A product manager, however, needs to do research that follows a path like the following:

Given that we are building an eCommerce website, we know that people have expectations around page load times (per Forrester / Akamai report (requires registration)).

[larger image]

Further, those expectations manifest as people abandoning slow-loading websites (from the same report).

[larger image].

We know from this market research that page-load times (for websites) represent another more is better Kano attribute, but one that has must be characteristics at the extremes.

[larger image]

While more speed is better, what the market research reveals is that for any given person, there is a minimum-speed threshold, at which speed is a must-be characteristic – too slow, and you lose customers (immediately).

A  combination of market research and elicitation will reveal that there is a true underlying goal of being fast enough to satisfy as many users as possible.  Combining this with practicalities of scaling your solution, and the associated costs; in the context of a particular solution design (an eCommerce website), you will arrive at a goal that allows you to rework your requirement so that it is verifiable.

Note: The requirement in this example is a subordinate requirement to a goal focused on maximizing conversion percentage (the percentage of customers who visit the site making purchases) – with a recognition that a major source of non-conversion is abandonment of the site, and that a large contributor to visitor abandonment is page load times.  An Ishikawa (or other model) will help you articulate this complexity and formulate requirements at a level of abstraction that is both valuable and actionable.

Rewriting the requirement as follows makes the requirement verifiable:

• Before: “The home page needs to load fast.”
• After: “No more than 10% of potential site visitors will abandon our site before viewing the page.”

Indirectly Verifiable Requirements

Some requirements are impossible to literally verify, and must be inferentially verified.

• The site must support 1 million visitors per day, with a peak of 10,000 simultaneous with page-load times under 5 seconds.

Models are Models, Not Reality.

Imagine trying to create a test by organizing a million visitors to hit your SaaS web solution on the same day, with at least 10,000 of them hitting the site simultaneously.  That is completely impractical.  That doesn’t however, invalidate the requirement or make it untestable.  The combination of modeling, hypothesis formulation, and extrapolation gives you a reasonable way to verify that your solution probably meets this requirement.

You’re already used to the concept that models are representations of reality – think about the maps you use – a map may have a scale like one inch equals one mile.  The map is a model of reality.  A map where one inch equals one inch would be impractical.

An effective approach to measuring this type of scalability requirement is to simulate users (with load testing and realistic user-behavior scripts) with automation.  That takes care of most of the coordination problem.  However, the cost of simulating a million users and 10,000 simultaneous users is high.  You can, more realistically, measure the site’s performance when 10, 100, and 1,000 simulated users simultaneously access a server.  You can extrapolate from those results to estimate how the system is likely to perform under 10,000 user loads.

Note: Extrapolation is dangerous (follow the Elvis link below)- you have to justify why extrapolation holds true, and identify when it does not, to minimize the risk of invalidating your hypothesis.  Make sure you have confidence in the engineering prowess of whoever is doing your extrapolation and modeling.

[see tip #5 of these ROI calculation tips for the Infinite Elvis anti-pattern]

While this requirement does not to be rewritten in order to be verifiable, it does need to be augmented:

• Original: “The site must support 1 million visitors per day, with a peak of 10,000 simultaneous with page-load times under 5 seconds.”
• Additional: “Testing of the site must show that 500 simultaneous users following <user script X> will yield no more than 1% page load times over 200 ms.”

Conclusion

Every requirement you write must be verifiable.  When you can’t verify something, and can’t rewrite it into a verifiable form, that should be a sign that either it is a vision statement or a red herring.  Vision statements guide how we approach creating products and engage markets – they are valuable, but they are not requirements.  Red herrings are well-meaning but ill-advised inputs into the process that need to be culled – they are neither valuable nor requirements.

Make sure all your requirements are verifiable.

People who already use Scrum will only find one new thing in this article – a way to communicate what happens inside a sprint that has proven effective for me.  People who are new to Scrum who wonder “how do things work inside a sprint?” will see how things work in a way that avoids hyperbole and is easy to map to what they already understand from traditional software development processes.

Two Teams Separated by a Common Process

George Bernard Shaw was an Irish author in London who memorably said “England and America are two countries separated by a common language.”  The same can be said about teams developing in agile and waterfall processes.

The story of agile adoption is one that has many colorful examples of adoption and of spreading the gospel.  Some practitioners traveled across the ocean from the agile continent to the lands of agile and opportunity to reap the rewards.  A few of those, after realizing the benefits of agile, invade our consciousness with a hellfire and brimstone tale of doom for anyone who doesn’t convert to the new religion.

Others seem hell-bent on kidnapping entire development teams, smuggling them across the ocean in the belly of steamer ships and unceremoniously dumping them in the land of agile, ready or not.  Scrum is but one branch of the agile movement.

Stalwarts of the old way, which has worked fine for me, thank you very much, refuse to leave their comfortable lives to step into the unknown wilds of agile.  Open-minded but responsible potential converts ask questions to gain an understanding of what life in the new world might be like.  What will life be like if I join this Scrum congregation?

How Does Scrum Really Work?

The best explanations of how scrum works that I’ve read come from Mike Cohn and Mountain Goat Software.  The training, videos, and explanations they share provide fantastic top-down introductions (as well as guidance after adopting Scrum).  His book, User Stories Applied, is the ultimate reference when gaining an understanding of the mechanics of using user stories as the central artifacts for developing software with scrum.

[larger image]

The process diagram above provides a good outside-in, top-down view of how “this newfangled process” results in shippable product, incrementally.  It is a great way to present the concept of Scrum, and incremental development in general.

When people I’ve worked with first gain this understanding, they often ask, what are the artifacts that live in these backlogs?  User stories live there.  Sometimes use cases make more sense than user stories for Scrum- it depends (read the article to see which works best in your circumstance).  The common element is an outside-in, user-centric approach to describing which problems the software is intended to solve.  This is also known as goal-driven development.

Once people understand the top-down view of the process, and have an idea of what user stories are, the next question they tend to ask is “how do stories move through the Scrum process?”

The first attempt at answering this question leans on the process diagram above:

1. The product owner takes the most important stories from the product backlog and puts them into the sprint backlog – collaborating with the team to agree on the scope of work for this sprint (based on the amount of work, capacity of the team, real-world constraints, etc).
2. The team “works the stories“, meeting every day to communicate effectively and provide progress updates – best visualized with a burndown chart.  This chart says “we started with X work to do, and every day, we track how much of X remains to be done.”
3. At the end of the sprint, the work is done, and the software (or an update to the software) is ready to deliver.
4. Sometimes, multiple sprints happen between releases – launches of the updated software, because customers (and the rest of your organization) incur a cost when changing to the latest version.  But the output of each sprint is deliverable – that’s a key concept – even if you choose not to deliver it just yet.

What Does it Mean to Work The Stories?

I’ve repeatedly had people ask, after absorbing the above explanation, “what does it mean to work the stories?”

I’ve had consistent success (in bridging the language divide) using the following diagrams (drawn on a whiteboard) to explain how stories flow through the sprint process in Scrum.

The first diagram shows that user stories have a structure – the story itself, and the acceptance criteria for the story. I also establish that the story is going to go through a life cycle within the sprint.

[larger image]

Next I remind folks that the user stories make it into the sprint backlog because they are the most important (highest priority) not-yet-implemented stories in the product backlog.

[larger image]

Developers on the team pull stories from the sprint backlog and begin working on them.  These stories are work in progress, and are owned by individuals.  Some teams maintain that priority order within the sprint backlog (e.g. implement the most important story in the sprint first, etc.), while other teams use a more coarse-grained approach, relying on the product backlog prioritization to assure that everything in this sprint is the next most important stuff, and the order that the team implements, within the sprint, is up to the team.  Some folks like to strenuously debate this decision (don’t prioritize within sprints vs. do prioritize within sprints).  Both approaches are valid, and you should choose the right one for your team.

[larger image]

As each user story owner believes that her work is complete (all unit tests pass, and the developer believes that the acceptance criteria have been met), the story is ready to be tested by QA.  This step, in particular, helps people who are new to scrum and who think of things as “code and test”, to make some sense of the inner workings of a sprint.  When working with a team that was under-staffed in the QA department, I discovered that calling out this queue of user stories waiting to be tested helped convince management to increase QA investment in the team.  When too many stories pile up here, you know you have a problem.

[larger image]

The scrum team member responsible for testing the user story has the responsibility of assuring that it meets all of the acceptance criteria.  He pulls the story from the queue of “done” stories, and tests.

[larger image]

If the story fails to meet any of the acceptance criteria, it moves back into either the sprint backlog or the being developed column, where a member of the team resumes ownership of the user story and works to resolve the issue.  Once the issue is resolved, the user story is re-queued for testing.  When the user story meets the acceptance criteria, it is moved into the done done column.

[larger image]

Conclusion

If you are new to Scrum, and wondered how the sausage is made inside a sprint, this gives you a framework for understanding what is going on, and how the team delivers.  If you already know or use Scrum, you may have learned a couple things.

• Using this framework to describe how a sprint works is effective when explaining to people who do not have any experience with agile.
• Laying things out this way visually, will give you an easy-to-see signal if your team is unbalanced between developers and testers.

I’ve been involved with agile teams and processes for just over 11 years now, and incremental development is burned into my brain.  If you are new to scrum, please let me know if this seemed like a good way for you to consume this material.  If you’re an old hat, and have other suggestions or presentations, please add them in the comments below, because future readers will benefit from the additional ideas.

Writing unambiguous requirements is about understanding what is written, and what is read.  Without a clear understanding of your market, you can’t write unambiguously.  Even when you understand your market, you risk writing something that is ambiguous to your readers.  Documenting requirements is about communication.  Don’t break this rule, or you’ve wasted all the energy you spent understanding your requirements.

Unambiguous Requirements – Revisiting

Fifty months and five days ago (another grin), I wrote about the importance of writing requirements so that they can be clearly understood.  Writing requirements so that there is one, unambiguous, interpretation of what you wrote.  This article is the seventh in a series on the rules of writing good requirements.  In that version of the article, I focused primarily on language ambiguity, and framed the discussion in terms of ambiguity to the writer and to the reader.

As part of improving that series, I am revisiting each of the articles now that I have fewer hairs and the remaining ones are more gray.  The same framework still applies, but will be expanded in scope, using the following modified definitions of the framework.

• Ambiguity for the Writer – not having a clear interpretation of the requirements.
• Ambiguity for the Reader – requirements that, as written, can be interpreted in more than one way.

It takes two to tango.  To lead, you have to know where you’re going.  To follow, you have to know where you’re being led.  The same is true with requirements – you have to know what you’re writing, and how your writing will be read.  Misinterpretation of requirements is the source of over 40% of all software defects.

Ambiguity for the Writer

When you don’t know why you’re developing a particular set of requirements, it is because you either don’t have sufficient understanding of your market, or of your corporate objectives.  While it is always a lack of knowledge, sometimes, that lack of understanding is insidiously hidden.  You, as the writer of requirements, are the reader of the market – and what you’re reading is likely to be ambiguous.

For Whom You Are Designing

The most overlooked element I’ve personally seen in product creation is failing to understand who the users and buyers of your product will be.  I wanted to type “forgetting to understand,” but I struggle to imagine someone who understands the value of defining user personas and buyer personas, who then forgets to define them when gaining an understanding of their market.

The reason that this is an ambiguity issue is that when you fail to define personas explicitly, you define them implicitly.  An implicit persona is an ambiguous persona.  Alan Cooper named this anti-pattern the elastic user, and the problem manifestation as failing to provide insight to guide design decisions.  When you have an ambiguous user, you lose what Frederick Brookes calls the clarity of design. This results in at best a mediocre product without a core idea or aesthetic.

Different users value the same solutions differently.  Users vary in competency, and therefore have varied personal goals as they learn how to better use your product over time.  When you don’t identify who the user is, you prioritize requirements without insight into what is important to the undefined, elastic, and ambiguous user.

The readers of your requirements are trusting that you will prioritize requirements correctly – but you can’t, because you lack an understanding of who the users will be.  You therefore lack an understanding of which problems are valuable, and which problems are more or less valuable than other problems.  This ambiguity makes it particularly difficult to write valuable requirements.

Precision in Language

The other aspect of writing unambiguously is in using language that has meaning.  Using words like “can” and “may,” is imprecise in requirements.  ”The system can respond in under three seconds.”  Does that mean that it must respond in under three seconds?  Does that mean it is acceptable if the system responds in twenty seconds?  This is an area of overlap with the rule of writing measurable, verifiable requirements, so I won’t go into more details here.

Another source of imprecision in language, not only for the reader, but also for the writer, is jargon.  You should never use jargon, as you have no way to know if your reader will actually interpret the jargon terms correctly – as readers often vary in the depth of their domain knowledge.  Jargon is also a high risk of ambiguity source, precisely because it is jargon.  Jargon is short-hand for communicating efficiently among domain experts.  Are you enough of a domain expert that you are confident that you absolutely, unambiguously understand the accepted meaning of the jargon term?

Hopefully, you’ve achieved a perfect understanding of your market.   Long-time readers will know that I’m joking.  Market analysis suffers from it’s own Heisenberg Uncertainty Principle – if you actually did manage a perfect understanding, the market will have changed – the best you can hope for is a statistical understanding of the behavior of your market.  You can document your interpretations, assumptions, and decisions – achieving clarity in your requirements – at least from your point of view.

Ambiguity for the Readers

As I mentioned earlier – using requirements is a dance – and it takes two, both the writer and the reader.  You need to write requirements so that they can only be interpreted in a single way, or you will stumble.

“You keep using that word.  I do not think it means what you think it means.” – Inigo Montoya (IMDB)

Shared Language

The word “shall” as in “the system shall…” can be misinterpreted when your readers don’t share the same native language as you – which is why you must always use “must.“

Some good research on vocabulary size data for comprehension of english can be found here. The average native english speaker knows 20,000 word families. With a vocabulary of 5,000 english words, only 98.5% of the words in a given text will be understood. 5,000 words is a lot for a speaker of a second language (3,000 words is considered aworking knowledge).

An analysis of the reading-level at which a document is written can be helpfull in identifying if the language is likely to be challenging for readers with limited vocabularies. The Gunning-Fog Index provides a measure of the education level at which a text is written.

Writing Unambiguous Requirements (2006)

Can’t write that section any better :).

Ambiguous Use of Language

I had the privilege to attend a presentation by professor Daniel M. Berry in 2007, on the ambiguous use of language in business rules and requirements.  In that presentation he referenced The Ambiguity Handbook that he authored (80 page pdf), which I just re-read last week.  There are many good examples of ambiguity in the use of English in business documents.

The following are some of the sources of ambiguity, for which I entirely credit professor Berry for pointing out to me.  I’ve only added some illustrative examples:

• Plurality Causes Ambiguity.  Consider “Emails must include sender addresses” and “emails must include recipient addresses.”  Must each email include one sender address and one recipient address?  Must each email include multiple sender addresses?  Solution – don’t use plural subjects.  ”Each email must include a sender address” and “each email must include recipient addresses.”
• Associative Ambiguity.  Professor Berry calls this the parenthesis problem.   What does “A and B or C” mean to you?  Does it mean “A, and either of B or C” or does it mean “either C, or both A and B” when you read it?  In math and programming, we learn very specific rules for how to interpret these types of structures.  We are also given parentheses, that we can use when we want to be specific and unambiguous.  The reader of your requirements is not a compiler, so don’t assume that she will interpret this the same way that you do.  Solution – use parentheses and explicit language to eliminate ambiguity that would arise from ignorance of the associative property.
• Anaphor Ambiguity.  For non-linguists: “don’t use pronouns.”  I love the example that wikipedia uses – “We gave the bananas to the monkeys because they were hungry.  We gave the bananas to the monkeys because they were ripe.
  
  We gave the bananas to the monkeys because they were here.”  The pronoun, “they,” has an ambiguous binding.  Should “they” be a reference to the bananas or the monkeys?  In each of the first two sentences, you could reasonably assume that the reader will properly bind “they” to the monkeys and bananas respectively.  In the third sentence, an assumption of how the reader will interpret “they” is not reasonable.  Reasonable assumptions are still ambiguous – and the context is less likely to be obvious – so don’t use pronouns and rely on readers to bind them to the appropriate nouns.  Solution – repeat the noun for every reference.

Incompleteness Ambiguity

Unwritten requirements are by definition ambiguous.  You must not assume that unstated requirements will be implemented.

A security exploit was recently discovered (and eliminated) in Facebook.  Previously, if you attempted to login to Facebook with an email address and a password that did not match the email address, Facebook would present you with a typical “failed login” screen and a link to reset your password.  However, in an effort to be friendly, Facebook would also include the first name and last name that were associated with that email account in the friendly warning message.

That is nice, except it is a privacy problem, and anyone who knew about this before could use the login page to discover the first and last name to associate with any email address.  ”Bad people” with email address lists could discover the name to associate with many of those email addresses – allowing more sophisticated phishing or social engineering attacks.

The requirement to not provide any personal information when a user fails a login attempt was almost certainly an unwritten requirement.

Conclusion

Precision in your writing will reduce ambiguity in your requirements.  Active listening will help you discover when ambiguity has slipped through your editing net.  You can never completely eliminate this problem, but you can improve.  You must.

As product managers, we talk about creating the right solutions with our products. Understanding the very real problems our customers face, understanding the very real opportunities our markets present, and manifesting that understanding in a product roadmap.

Other than being “not as good,” how expensive is it to build the wrong product?

The Cost of Poor Quality

There’s an analog to the market dynamics of making poor product decisions – executing with poor quality. Many research studies and articles have identified the market impacts of poor quality.  This has become so well accepted that people today cite it like a law of physics (one example here based on this 1988 IEEE research by Barry Boehm and Philip Papaccio) as the “1-10-100 rule.”  The primary conclusion of that research is that ten dollars spent on fixing bugs:

• Costs and saves $10 when you catch (and fix) the bug during implementation.
• Avoids $100 in costs when you catch the bug during QA and send the product back to development (then test again).
• Avoids $1,000 in costs versus waiting until your customers catch the bug in the field, causing the team to remedy the problems, rush out a patch release, and/or go to heroic lengths to manage a PR problem.

This is an opportunity in front of your product team – a 100x payback from investing in quality during the development process.  Of course, be pragmatic about it - if the cost of testing exceeds the cost of bugs, don’t test.

This is not a solved problem, by any stretch, but the solutions and methods to solve this problem are well understood now.  In fact, a 2001 article by Barry Boehm and Victor Basili shows that in some cases, the labor costs to resolve bugs can be as low as 5:1 – when considering a subset of smaller systems, when using more “agile” processes.  That lowered ratio does not take into account the lost market opportunities and the costs of cleaning up collateral damage to your product – just the immediately realizable (and measurable) costs of resolution.

One very real problem, when talking about “bugs” is in defining what a “bug” is. And the definition of a bug is a matter of perspective. A developer can reasonably assert that “if it meets the spec it is not a bug, it is working as designed.” What if the spec is wrong? The developer may not be guilty, but collectively, your team screwed up. There’s a “bug” in the requirements.

What Is A Requirements Bug?

Now things are getting interesting.

If you wrote a requirement that you interpret as “A” and your developers interpret as “B” – you definitely have a bug – the team won’t build the right product. For each $1 you could spend making sure you have bug-free requirements, you could:

• Make sure you have a shared understanding of the documented requirements through active listening before development begins ($1). Following the Rules of Writing Requirements will help prevent this miscommunication.
• Wait until the engineering team is ready to demo their progress ($10). They will have to build it again, because they built the wrong stuff.
• Wait until development is complete and QA is validating that the code meets the spec ($100). This gets tricky if you are thinking “A”, the developers are thinking “B”, and QA is thinking “C.”
• In classic throw-it-over-the-wall mode, wait until the product is launched, and it is the wrong product ($1000). Assuming “A” was the right problem to solve, the cost of entering the market with a solution to “B”, leaving “A” unaddressed, is impressively high.

This gets interesting because the above assumes that “A” was the right problem to solve. What if “G” was the right problem to solve, and “A” was the wrong market problem? Even if everything (else) is working perfectly – you document requirements for “A”, the engineering team creates a marvelous “A” and it launches without implementation errors – you still fail, and incur the 1,000x cost of a failed product launch.

There is an even larger opportunity in front of your product team – a 1,000x payback on discovering and choosing to solve the right problems for your customers and markets.

• Would Palm still be independent if the Pre had solved a compelling problem?
• Why did Intuit have to buy Mint.com – could they have embraced the same customers with Quicken?
• What is Garmin going to do now that “free” GPS mapping and turn-by-turn directions are becoming ubiquitous? If it is “more of the same,” how much are they wasting?

Wrapping Up

I’m not aware of any studies that show that “requirements bugs” fit the same 1/10/100/1000 cost explosion model that “implementation bugs” exhibit. Emotionally, it “feels about right” to me – it passes my “sniff test.”

There are times when days of research would have been required to avoid or redirect a few hours of implementation effort on projects I’ve worked on. And I’ve seen man-years invested solving problems that didn’t involve much more research.

My intuition from products and teams I’ve worked with is that it probably averages out somewhere around 10x.

What does your gut (or your data – if you have some, post a link below!) tell you?

“For what one idea do you want your product to stand in the mind of your customer?”  I heard Roger Cauvin ask that question at the most recent ProductCamp Austin [correction - he said it here - thanks Roger], and the quote has been jumping to the front of my mind almost daily ever since.  Maybe by writing about it I can exorcise the demon and get back to using the idea instead of being haunted by it.

The One Idea

You’ve just been given a new assignment – your company needs a new software thingamajig so that you can play in the whatchamacallit space, and you’re going to drive product management for it.  You’ve also been asked to deliver the first version in six weeks.  Of course you’ll be able to do follow-on releases, after all, you are agile.  That’s how “agile” works, isn’t it?

Cool.  Exciting.  Challenging.

You sit down with the folks who will be building the product, and find out that they have already spoken with several stakeholders.  Excellent. You circle back with the stakeholders, and start to gather data about your market and audience.

Your schedule is aggressive, so you think about what is realistic to get done in a very small timebox.  With the current schedule, you can’t afford to get caught in analysis paralysis, and you can’t realistically do in depth market analysis, persona development, hyper-accurate requirements prioritization, etc.  You do, however, have time to do the most important thing – define the one idea that will define your product.

If you cannot come up with this idea, you need to push back on your management team, and delay the launch of your product until you have that one idea.

Don’t Abuse Agile

Agile is designed to help you rapidly create iteratively better products, with iterative development and continuous infusion of market feedback and data.  Agile is not a process by which you start typing without any idea of what you intend, releasing it and then getting feedback in an iterative process.  If that’s how you’re approaching agile, your process is broken.

[image from Market Driven Competitive Advantage]

Unless you’re very lucky, your first iteration will be a waste of time and money.  Wouldn’t you rather be intentional than lucky? Make sure you have that one idea before you start developing.

Strategic Alignment

You need to come up with a one idea that is aligned with and supports your corporate strategy.  At a minimum, you have to make sure that you have an idea that is aligned with your stakeholder’s goals, based on the assumption that those goals are aligned with corporate strategy.

Wow

Your one idea really needs to make your users say “Wow!”

I was explaining the importance of this to a colleague (who is not a product manager), and his response was “Oh, you mean the hook.”

I was reminded that you not only have to provide a wow experience for your users, but you have to present a hook that will capture the imagination of your buyers.  Remember that buyer personas make decisions based on their perceptions of user problems [more on convincing buyers].

Satisfice

Remember that you don’t want to try and do everything perfectly in the first release – you want to satisfice.  You may only be able to target a single persona with a solution to a single problem.  You just need to make sure you are solving the right problem – which is where Kano analysis is very handy for identifying the Minimum Market Acceptance criteria.

[From Minimum Market Acceptance]

Conclusion: A Balancing Act

Defining the one idea for your product is a balancing act.

• You have to align the one idea with your corporate strategy and stakeholder goals
• You have to solve a valuable problem for your users, presented in a way that captivates your buyers
• You have to create a product that is compelling right away – good enough in execution to enter your market
• And you have to get the first release out in six weeks!

Good luck!  Or better yet – Good Intent!

Consistency in writing requirements is important on two levels – strategic and tactical.  Tactically, you need to write your requirements with grammatical consistency, so that potentially ambiguous statements will be interpreted similarly.  You also need to write requirements that are logically consistent, so that you avoid “impossible” requirements and gaps of unspecified meaning.   Strategically, your requirements need to reflect a focus on markets and problems that are consistent with your business objectives and the vision your company is manifesting

Consistent Requirements – Revisiting

Thirteen hundred ninety-six days ago (grin), I wrote about the importance of grammatical and logical consistency in writing requirements – an emphasis on the tactical aspects of consistency in writing requirements.  This article adds a brief discussion on the consistency of the requirements you write.  This article is the sixth update of a series of articles on the rules of writing requirements.

Grammatical Consistency

[source]

Writing requirements is not like other forms of writing in one key way – you don’t want to vary the terms and language you use in your requirements documents.  Remember the critiques you received when you studied writing in school for a moment.  Your teacher told you not to repeatedly use the same word, but to use synonyms for that word – walked, ambled, stepped, capered, etc.  Those synonyms allowed you to create imagery and helped your readers avoid boredom.  Your teacher encouraged you to use metaphors that created even stronger imagery – flew, slogged, muddled, danced, etc.  Those metaphors allowed you to infuse emotion into your narrative and helped your writing come to life for your readers.

As Yoda said, “Unlearn, you must!”

Requirements are not a narrative.  Your primary goal is not entertainment, it is enlightenment.  Don’t use varying terms to describe the same action or object – use the same terms over and over again.  Don’t vary the modifiers of terms except when you are explicitly varying the context and referenced items – and then make certain that you use the same modifiers consistently for the same context and references.  When dealing with anything that has some complexity, provide a figure or diagram (possibly in an appendix or glossary) that explains the explicit meanings of each term and term-modifier.

For example, if you are defining requirements for a classification system for authored works, be specific about the definitions of author, editor, publisher, and reviewer.  You may also need to define a term that is used collectively for all of them, like creators.

You must consistently use the same voice  - ideally the active voice.  And of course, you must not use ‘the system shall.’ [There's a great debate in the comments on that article - one thing to note - all of the people on both sides of the debate emphatically expressed their consistent use of one form or the other.]

Logical Consistency

[source]

Logical inconsistency most commonly comes from expressing the same requirement twice.  If you use the exact same words to express a requirement twice, you’re being redundant and repetitive (grin #2).  Most likely, the second expression of the same requirement is both unintended, and worded differently – running the risk that it will be interpreted differently, and therefore inconsistently.

You will also create logically inconsistent requirements when you express mutually exclusive requirements.  These can be directly incompatible, like writing “the system must infer the value…” and “the user must provide the value…”   Or they can be indirectly inconsistent like “the animal must bark” and “the animal must be a cat” – which is logically inconsistent because cats cannot bark (thereby making at least one of the requirements infeasible).

Strategic Consistency

One of the elements that defines valuable requirements is that they “support your business strategy.”  In the context of value, that means you have created a decomposition model for how you intend to realize value – manifesting a strategy or a component of a strategy.

A strategy, however is not always defined by a single measure.  Your strategy could include financial metrics and targets, as well as a stated mission regarding customer service levels, and a long-term investment that is hoped to eventually return long-term rewards.  Your requirements, while not only completely defining the mechanisms for achieving value, must also be consistent with the other elements of your strategy.

For example, you should not take advantage of uninformed costumers when you have a core value of integrity – regardless of how effective that may be at meeting financial goals.  The requirements that articulated the (subordinate) goal of grifting your customers (to maximize revenue) would be inconsistent with the goal of operating with integrity.

Conclusion

Consistent Requirements are requirements that

• Are not in conflict with any of your strategic objectives, vision, or corporate goals
• Avoid logical inconsistencies
• Utilize consistent structure, terms, and grammar

April Dunford just presented Startup Marketing 101 at DemoCamp Toronto.  Great ideas from the ‘marketing and your startup’ point of view.  I’ve often said that product managers and product marketers care about much of the same market data, they just do different things with it.  The idea of minimal feature set came up in April’s presentation – this article talks about product management, agile, and initial market acceptance.

Initial Market Acceptance and Minimum Market Acceptance

April mentions (in slide 4) that an important event to the timing of marketing activities is achieving the “_minimal feature set (for certain markets)_.”  April organizes those marketing investments in terms of three stages of “product marketing lifecycle”:

1. What to do when your startup has a “pre-product” product.
2. Where to focus when you’re focused on early adopters.
3. How to invest in your marketing programs when your focus is on scale / growth.

Coming from an agile background, I think about two distinct notions of “minimum” or “initial” when it comes products and markets.  The following definitions are in a B2B context, as I’ve been focusing on this recently with a client in the B2B space.  The same ideas are relevant to B2C and B2B2C companies, but the language would be slightly different.

I’m assuming that when April used the phrase “minimal feature set”, she was really talking about “minimum market acceptance” in the way that I’m describing here.  The distinction is that features describe what a product does, which is an inside-out view of the product.  To be market focused, you have to think about which market problems are being solved, for whom they are solved, and how well they are being solved – an outside-in product view.

If you focus on, and organize around your features, you are likely to miss the mark.  You must focus on the problems that your customers need to solve.  In your product, you will prioritize the development of capabilities (embodied through features) that are designed to help your customers (buyers and users) solve their problems.  Your market analysis should be geared around understanding how many customers in each segment face each problem, and how much they are willing to pay to solve those problems.

Agile or Waterfall or Waterfragile?

As an agile product manager, and former developer, I know that when you do “everything we need to be successful” in the first release, you’re not being agile – we’re being waterfall.  A slight extension of this is “everything we need to be minimally successful” – and that is still waterfall.

An agile team should focus on the first release addressing the initial market acceptance criteria – the minimal set for a single customer.  The goal is to get the product in front of customers as soon as possible – this starts your revenue stream earlier, gives you valuable market feedback, and gives you the opportunity to establish momentum through repeated incremental releases of your product.  Each release will solve addressed problems “better” and / or address additional problems, until you reach minimum market acceptance.

Kano Analysis for Understanding Problems

Last year, I was thrilled to share my approach for applying Kano Analysis as a product manager with the PMV webinar audience as well as the Austin IIBA chapter.  One of the key ideas in the application of Kano Analysis to understanding your market is developing the personas within that market, and understanding how each of them treats each problem / capability.

[slideshare presentation & PMV webinar]

This analysis, in addition to being useful for understanding the market (or a segment) as a whole, also helps you identify your first customer.  Once you know who your first customer is, you can determine the initial market acceptance criteria for that customer, and that determines the must have capabilities.

Note that finding the initial solution (that the first customer will buy) does not mean releasing a poor quality product – it just means releasing a product that solves enough problems (well enough) for one customer.  With the feedback from that customer, you can drive the prioritization for your next iteration – making the next iteration better for that customer (which can really help your word of mouth), and gaining more customers.  Repeat this process until you get to minimum market acceptance.

Timing Marketing Investments for Minimum Market Acceptance

[slide 9 from April's presentation on slideshare]

Since I wasn’t at April’s presentation, I don’t know exactly what she would think of the following, but I believe it makes sense:

• Initial Market Scceptance (one customer would buy your product) marks the transition from pre-product to early adopters.
• Minimum Market Acceptance (enough to succeed in the market) happens before the transition from early adopters to scale.  Note that it may not (probably doesn’t) mark the transition, but I suspect happens mid-stream.

Would love to see what other folks think about mapping this product management centric view to the marketing timeline.  Please chime in below.

One of my colleagues got into a debate with one of his colleagues about the differences between goals and requirements.  His opponent fired the following salvo: “[That] is not a business requirement in any company of the world…”

What you call your requirements is less important than how you communicate them.

Labels

I’ve worked with a lot of companies that use different labels to describe their descriptions of the problems that need to be solved. This is not another article about requirements versus specification (specification = design constraint, btw).

If you’re not a long time reader who’s followed the debates and discussions on this topic in the past, check out these articles and comments, where we’ve had some great discussions on that topic – with particular thanks to Roger Cauvin for keeping the debate front and center.

• Requirements Versus Design: Which is Which and Why
• Requirements Docs – One Man’s Trash is…

The central theme is that the debate about “what versus why” centers around differences in people’s perspective on the problem.

This challenge is not really about that (but it makes for good background).  The complaint my colleague received was really a critique of the way that the why of a set of requests was communicated and labeled.

Actionable Goals

Companies have strategic goals (increase shareholder value, gain market share, etc) that serve to guide the investments and activities of the organization.  However, for the teams that are creating products, those goals are too vague to be actionable.  I guess this is where my set of labels comes in.  I don’t think the labeling of a goal as a goal (versus labeling it as a requirement) is abstractly important, however, when people value making a distinction, here’s how I do it.

A goal is something your business (or user) is trying to achieve.  It is too abstract to have a single valid solution approach.  Once your business stakeholder(s) decide on a strategy by which they will achieve that goal, the business will define requirements for the actionable project(s) that execute this strategy.  This is an ideation step that lives inside the “why” box from a business analyst’s perspective.  Here’s an example:

Warehouse Manager

You’re in the IT department of a large company.  You’ve been assigned to support the warehouse manager (or COO, or vice president of order fulfillment or whatever).  Your warehouse manager is responsible for procuring the products that your company sells, keeping inventory on hand, and delivering those products to customers when they have been purchased.

Your warehouse manager is measured (or promoted) based on her performance relative to the following:

• The time that a customer has to wait between placing an order and receiving the product.
• The cost impact of warehouse operations on the products.

Your warehouse manager focuses on these two metrics because of your company’s goals – provide good customer service, be profitable, and grow revenue.  Those abstract goals influence product pricing – it must be low enough to grow revenue in the target markets, and be high enough to be profitable.  Since market pressures drive pricing decisions, typically a profitability target will then create cost-reduction pressures (profitability also influences pricing decisions, selection of markets, positioning within that market, etc).  A customer service strategy can also include a “you get your product quickly” component – as it does in this example.

Your warehouse manager now comes to you and says “I have an initiative to lower costs.”

Is this a goal or is it a business requirement?

Ultimately, it doesn’t matter what you call it, but for you to actually do something you need to know more.  That’s why my approach is to call it a goal.  Your warehouse manager’s problem is to lower costs.  You need to decompose that problem to understand how you (and your team) can do something to help her achieve that goal.  The reason you have to do that is that you need a problem statement at the right level of abstraction.

In elicitation conversations with your warehouse manager, you learn that all of the costs of operating the warehouse are allocated to the different business units, who operate as profit centers.  The warehouse operates as a cost center.  The warehouse manager treats each business unit as a customer, and provides a service of “fulfilling product orders” in exchange for funds that cover the costs of operation.  The allocation of costs is done per product that appears in the warehouse.  Since allocation is per product, it could be something like $1.30 per product in “warehouse costs.”  There are multiple sources of those costs (that are then allocated per product), and there are multiple ways to approach reducing the cost per product.

Your warehouse manager develops a strategy (probably a “mini-strategy” from the company’s perspective) to lowering costs.  She rules out “sell more products” as an approach, because she can’t control that.  She also can not affect her fixed costs (rent, depreciation, labor).

Eventually you discover that there is another cost hidden in the provisioning model – products are purchased, they sit in the warehouse for a while, then they are sold and delivered, and eventually money is collected from customers to pay for the products.  Your company has to pay in advance for the products, and doesn’t get their money back until funds are collected from the customers.  That money is “tied up in inventory” when it could have been invested otherwise – so there is a cost associated with high inventory levels, that directly correlates with the amount of inventory in stock.  When a new version / revision of a product is introduced, your inventory may become obsolete (it is definitely devalued).  And since markets are moving targets, your prospects of selling a product change over time – a risk that you will not be able to sell all of your inventory.

At the end of the day, the amount of inventory you have on hand has a cost.  The more you have, the more it costs.  A rule of thumb I heard 20 years ago was that inventory costs could be as high as 1/3 of the cost of the product for each year you keep it around.  If that is true, that is something like 0.5% added cost for every week the product is in inventory.  Here’s something the warehouse manager can potentially control.

Currently, your warehouse manager has 8 weeks of inventory on hand (on average) for products, which allows her to ship quickly.  She realizes she is adding 4% to the cost of the product.  She decides that if she can cut those costs in half, she will be a heroine.

Her business requirement is to reduce inventory levels from 8 weeks (on average) to 4 weeks (on average).  She also has a constraint that no more than 1% of orders be delayed by more than a day (due to running out of inventory).

Now you have requirements that are unambiguous and measurable.

Conclusion

Don’t trap yourself in worrying about the labeling of goals / requirements, but if you have to work with someone who does find that really important, before you call it a requirement, make sure it is at the right level of abstraction.  And of course, make sure you follow the rules of writing requirements.

I came across a really interesting article LukeW.com, showing how making changes to the way an input form on a website increased interaction by 25 to 40%. The changes reflect the value of thinking outside-in, investing in user experience, and performance measurement.

Bonus: the idea is cool.

Mad Libs Input Form

[full size image available in Luke's article]

The idea being presented is to replace the old boring web input form designed for a computer. The new, fun form is a fill-in-the-blank (aka Mad Libs) layout. The article is on Luke Wroblewski’s site.  The team at Vast.com created and tested a version of this form for the Kelly Blue Book site. [Luke cites Huffduffer.com as the first place where he saw this technique.] Thanks, Luke for sharing this with all of us!

Outside-In Development

Product managers are acutely aware of the need to solve market problems. We are regularly reminded that we’re creating solutions for people in our markets who use our products to solve their problems. When we write requirements, we avoid writing design specifications, and thereby lose the ability to enforce that the proposed solutions also take an outside-in approach. We maintain an outside-in perspective, but we lost the ability to influence an outside-in aesthetic.

Note: Outside-In Software Development is a great book, you should read it.

That’s one area where user experience works well in concert with product management – assuring that the same drivers of what to build are informing the design of how it is built.

The genius (or at least elegance) of this Mad Libs form from Vast / Kelly Blue Book is that it humanizes the experience of requesting that a nearby dealer contact you to discuss a possible purchase of a car from them. The forms we’ve all had to fill out on countless web sites are very inside-out. They expose the inner workings of the program – “gather this info, and that info, and this other info.” Those forms force users to do what the program wants. Blech. The form that Ron Kurti designed, however, forces the program to do what the users want. Huzzah!

Bad Requirements Prevent Elegance

I’ve written about the importance of writing design-free requirements several times.  Avoiding design constraints in your requirements is even one of the pillars of the big 10 rules of writing requirements.

If you had written the requirements for this contact the dealer page, would you have specified the design of the form?

Most of the requirements analysts I’ve worked with would have. I’ve even worked with companies that have developed templates / stencils defining how these interface specifications must be documented – requiring that all the fields be aligned, with specific pixel gaps, etc.

If you had specified the design (read: limited the choices of the designer), you would have prevented this solution.

Mr. Kurti’s elegant solution is clearly better.

One way to write the requirements that would not have prevented this solution would be with a user story and acceptance criteria:

As a car-shopper, I want to engage a car dealer, once every few years, so that I can purchase the car I selected.

• The car-shopper can provide his contact info (name, email, phone) for the car dealer.
• The system will display the information identifying the selected vehicle.
• The system will display the information identifying the dealer being contacted.
• The system will include an opt-in newsletter-subscription option.
• The system will notify the specified dealer when the car-shopper indicates.

The user story nudges the developers into an outside-in perspective by emphasizing the user’s goal. The acceptance criteria make it clear that any solution that meets those criteria is acceptable to the product manager. It allows the interaction designer to create a compelling solution, rather than forcing him to recreate a boring experience.

Measurement Rocks

The Vast team measured the impact of making this change to their form, and saw between a 25% and 40% increase in conversion (people contacting dealers versus people abandoning the process when they see the form). That’s a lot more leads for the dealers, and presumably a lot more money for Kelly Blue Book and Vast. This is a great example of how you can measure the impact of investing in user experience, because it should spark ideas for you.

What can you measure and test and improve?

Now that’s ROI for you.

You give your requirements to the engineering team, and they look complete.  The team builds your product, you launch it and the market soundly rejects it.  Why?  Because your requirements weren’t complete – they didn’t actually solve the problem that needed to be solved.

Complete Requirements – Revisiting

Going back almost four years, I wrote Writing Complete Requirements, as part of the Big Rules of Writing Requirements series.  That article centered on two key ideas of requirements completeness.

• Data, not opinion, is the most important input into determining completeness.
• There is no absolute way to determine the completeness of your requirements in advance.

Completeness is best measured by market acceptance, so technically you can’t know if your requirements were complete until your customers buy (or fail to buy) your product.  This doesn’t mean you should give up on this rule of requirements – you can still focus on, and improve, the completeness of your requirements.

Objective and Heuristic Assessment

Given a market problem and the associated requirements (which you can argue are actually the same thing), you can review those requirements to determine if they objectively appear to be complete.  This assessment is based on what you objectively know about your market (needs, opportunity costs, competitive alternatives, etc).  You can also apply heuristic, or logical analysis to identify gaps in the language of your requirements.

Objective assessment is the application of market knowledge (data) to determine if the nature of the problem is being addressed completely by your requirements.  A bird-feeding maven would know that the requirements for your bird feeder would be incomplete if they didn’t address the problem of squirrels stealing food from the birds.

Heuristic analysis is the identifications of logical omissions in your requirements, without the need to apply market insights.  A logician would know that the requirements for your bird feeder were incomplete if they didn’t address the need to refill an empty feeder.

When you’re writing requirements, you need to do both.  Heuristic analysis of your requirements will identify where your requirements do not fully solve the problems you already know about – an eCommerce checkout process without the ability to receive payment, for example.  Objective assessment will help you identify the problems that you overlooked but need to solve – the need to allow customers to have different billing and shipping addresses when placing an order online, for example.

Complete Requirements for Incomplete Solutions

Don’t confuse having complete requirements (a good thing) with completely solving a problem (not always a good thing).  In agile development, the idea of satisficing is key to scoping individual iterations.  The idea, simply put, is to solve enough of the problem, and not delay delivery (and value) until you can build a solution to the entire problem.  Because of the law of diminishing returns, for many market problems, there is little or no incremental value in solving the entire problem.  Those resources can be better applied to solving additional problems.

Kano analysis provides a framework for identifying which market problems must be completely solved, and which ones have a more is better characteristic.  In practice, more is better problems exhibit the law of diminishing returns, and should not be “completely” solved.

[larger image, or view the entire Kano analysis presentation]

Conclusion

Complete Requirements are requirements that

• Identify all of the market problems that need to be solved and their nature (absolute vs. diminishing returns).
• Are logically complete in their coverage / articulation of those market needs.

To objectively improve the completeness of your requirements, apply market data in an assessment of your requirements.  To heuristically improve the completeness of your requirements, look for logical inconsistencies and gaps in reasoning or coverage.

Engagement – that’s what this whole product management blogging thing is about.  Check out what Tyner Blain readers found to be the most engaging articles in 2009.

Deep Dives

If you’re new to Tyner Blain, you may be surprised by the length of the articles here.  I joke that they are long because I don’t have time to edit.  Stewart Rogers jokes that they are long because I’m incapable of writing a short article.  If you’ve been here a while, you know what you’re in for.  If you’ve been here a long while, then you’re glad (like me) that I don’t write one per day any more.

Product Management is simultaneously a broad and deep discipline, requiring us to have a breadth of perspective combined with a depth of insight.  We then have to apply that in a market context, effectively navigating the political waters of our organizations.  Most of the articles here either try to skim the breadth of a range of related topics, or plumb the depths of a single topic.  Doing that in under a thousand words is pretty hard.  Most of the articles here also link to other articles, to try and provide even more depth and context, and encourage additional critical thinking.

One measure of the quality of the articles here is how often they stimulate readers to read further, or dive deeper into the topics.  While web analytics won’t allow us to measure how thought-provoking an article is, we can look to see how many people dive into the linked articles, versus how many people move on to something else.  We can measure the bounce rate of an article to see how often people leave a page without following any of the “tell me more” links.

Looking at ~170,000 page views at Tyner Blain in 2009, narrowed down to only those articles with at least 100 page views, here is the top-ten list of most engaging (or “least abandoned” if you’re a “cup is half empty” person) articles:

1. Use Case Series: Introduction: A collection of articles on the “traditional” forms of use cases – informal, formal, UML.
2. Agile Development of Use Cases: A dive into the dynamics and cadence of an agile process for developing use cases.
3. How Do You Manage Market Data?: A collection of articles exploring different market-immersion techniques in depth.
4. Scheduling Requirements Changes – Part 2: A focus on practical techniques for managing change with an agile development process.
5. Yesterday’s BPMN Post Was A Big Fat Lie: A mea culpa and clarification of interest to folks following the BPMN Series.
6. Everything I Needed To Know I Forgot in Kindergarten: Why asking why? is important.
7. Plan Your Next Sprint by ROI – Part 1: Prioritizing by Bang for the Buck, not just Bang.
8. Ten Common Mistakes of Going Agile: A collection of articles about common pitfalls encountered when adopting agile practices.
9. Perpetually Almost Finished Projects: Organizing a project with discrete deliverables and rolling-wave planning to avoid the “90% done, 90% remaining” problem.
10. How To Use Timeboxes for Scheduling Software Delivery: One of my personal favorites.  A rational approach to making trade-offs when your “perfect” plan has to change.

OK Stewart, that’s only 519 words.

Unless you live in a world filled with unicorns and rainbows, writing realistic requirements is critical.  When you set unattainable goals, the best result you can hope for is a frustrated engineering team.  Write requirements that are attainable, and your team will surprise you with what they can achieve.

Attainable Requirements – Revisiting

A little over three years ago (ten unicorn years), I wrote Writing Attainable Requirements, as part of the Big Rules of Writing Requirements series.  In that article, we focused on the unique situations that every team faces – politics and people, and the shared challenge of implicit practicality.  Those factors are as important today as they were then.

Defining Attainable

Attainability, for requirements, is simply the answer to the question – can this be reasonably done?  Most, but not all, of the answer to that question comes from understanding if your team can build and test a solution to the problem you identify with your requirement.  Being able to create a solution requires that the problem you’re solving is tractable, and that the team creating the solution has the skills to solve it.

Being able articulate a problem and it’s solution is necessary, but insufficient – solving the problem requires that there be a feasible solution.

As the founders of the agile development movement explained in their pitch for “low overhead” process – people trump process.  I think it was Alistair Cockburn who added, “but politics trumps people.”

Finally, process is the often-overlooked element of determining attainability.  Realizing the benefits of a novel solution to an existing problem usually involves process changes – sometimes significant ones.

The next few sections go into more detail on each of these – tractability, feasibility, people, and process.

Tractability

Goldilocks ruled out the large bed because it was too large.  Eating the elephant, drinking from the fire-hose, boiling the ocean – these are all common phrases in the American vernacular, because so many people try to do too much (at one time).  There are many ways to decompose a large, intractable problem into smaller, addressable components.  Practicality requires that the problem you’re trying to solve is not too large.

If everything you do is small, however, you won’t ever accomplish anything big.  That’s where strategic product management shines.  As part of understanding your market, you identify large, valuable problems to be solved.  To solve those large problems, you have to break them up into smaller problems, and then address them individually.  You also have to make sure your team understands the big picture and the larger problem that ultimately needs to be solved.  A great way to share context while decomposing problems is with the use of Ishikawa diagrams.

And zooming in…

Maintaining context is a particularly critical component of working with agile teams, where each deliverable’s possible size is constrained further to what a team can accomplish in an iteration.

[click for larger version]

For some problems (and some teams!) this may be enough information to provide the context to develop a product backlog.  And your agile team will move forward into managing their own execution from the product backlog stage.  For larger or more complex problems (such as this example), you will need more detailed communication before diving into user stories / use cases.

The same Ishikawa diagram, with more detail, looks like the following:

[click for larger version]

Agile Product Management: Providing Context

This reduced granularity represents the smallest go-to-market atomic requirement.  Further decomposition results in smaller requirements, but they become too small, because they are no longer independently valuable.  I’m not talking about “the sum of the whole is greater than the sum of the parts” stuff here – I’m talking about “if you only get X, without Y and Z, it has no value” stuff.

Feasibility

Even after decomposing market problems into addressable chunks, you still have to make sure that there are feasible solutions.  One of the brighter software developers I worked with back in the day used to say “We’re writing software – it’s all ones and zeros – we can do anything.”  He also followed that up with “…but should we be doing that?”  The team I was working with at the time probably could do just about anything.  But not everything can be done with a given budget and a specific deadline.  Some things are simply infeasible.

Scrum teams measure velocity – a reflection of how much software they deliver in a given iteration, as a function of how much work they believe is involved in delivering.  This is a great “protected” measure of efficiency.  The team is protected from requests to do work that has little or no value – by measuring throughput in terms of effort, a team can get more efficient at doing more.  A requirement is infeasible, and therefore unattainable, when it exceeds what the team can accomplish given a fixed amount of capacity.  Project managers refer to this as the Iron Triangle – given scope, cost, and quality, pick any two as inputs and the third will be a variable output (absorbing the impact of uncertainty that arises during the development process).  I prefer to use timeboxes rather than that rusty old triangle, to emphasize my perspective that quality is inherent in delivery, and should not be a “variable output of uncertainty.”  Because quality is what usually bears the brunt of uncertainty.

plus  yields

When the solution to a defined problem is prohibitively expensive, it is not attainable.  The notion of cost should also be considered in the context of value.  Requirements with higher value can justify implementing solutions with higher costs.

Prohibitively expensive solutions make requirements unattainable.  Relatively expensive (relative to their value) solutions also reflect unattainable requirements.  You need to collaborate with your implementation team to understand the costs associated with any particular requirement to know if it is attainable.  This is one of the strongest arguments against throw-it-over-the-wall interactions between product managers and implementation teams.  Without that feedback about feasibility and cost of a solution, you can’t assure that the requirements you are proposing are attainable.

Regular readers of Tyner Blain will realize that this is just an alternate way of stressing the importance of considering ROI when defining requirements.

Politics

There are political realities that every organization faces.  It could be a benevolent dictator CEO, or an executive with an agenda or pet project.  It may simply be that there is value in the problems you’ve identified, but solving them is not aligned with your corporate strategy.  You may be focusing on dominating an existing market, where expansion into new markets is the company’s focus – or vice versa.  You may be focusing on top-line growth opportunities, while the company is fixated on cost-reduction in a time of economic contraction.

Each of these scenarios causes you to be fighting an uphill battle internally.  When that hill is too steep, you’re writing unattainable requirements.

Process

When deciding what to build, you also have to think about how you launch.  Launching, as Dave Daniels regularly points out on his Launch Clinic blog, is not just putting your product up on your website for sale.  You have to think organizationally about all of the other moving parts:

• Do your customers have the ability to absorb an update to your software?
• Can your customer service reps be trained in time to promote and support the new capabilities?
• Will your sales team be able to communicate a message that helps them close deals based on what you’ve just built?

Process is more than just the process of typing, compiling, and testing code.  Process includes everything needed to successfully go to market and sustain your product.  If you’re defining requirements that are too far ahead of your market they are not attainable.  If your requirements embody process changes that are too difficult or expensive for your customers or your organization to absorb, your requirements are not attainable.

Conclusion

Attainable requirements are requirements that

• Have a reasonable cost to implement,
• Are aligned with your company’s strategy and stakeholder’s agendas, and
• Result in solutions that can be consumed by your company and your customers.

Make sure you’re writing attainable requirements.

Design-Free requirements are important for two reasons, and hard for two other reasons.

Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.”  Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.

Design-Free Requirements – Revisiting

It has been three years since I wrote Writing Design-Free Requirements as part of The Big Ten Rules of Writing Requirements.  In that time, agile development practices have moved from being an esoteric development methodology to being the topic on the tips of everyone’s tongues as executives and organizations try to either (1) get the benefits of the state of the art in software-development process or (2) do something shiny and fashionable.

The previous article centered on elements of designs within MRD, PRD, and SRS artifacts.  A regular alphabet soup of artifacts.  Honoring the values behind the agile manifesto encourages us to emphasize working software over comprehensive documentation.  In that light, we’ll take a “what is needed” approach to talking about how requirements, design, and implementation are all needed – rather than issue an edict about where that information should be captured.

Agile Development Inputs

When creating software, someone needs to know:

• What problems are being solved, and how important (valuable) they are to be solved.
• Who has the problems and who is using the software to (help) solve those problems.
• What constraints limit the space that defines the universe of possible viable solutions.
• What acceptance criteria define if the delivered solution will be acceptable.

Subject to those inputs, someone needs to make design decisions:

• User experience design - what interactions will a user of our solution love?
• Program design – how (in a nuts and bolts way) will our solution function?

When talking about agile and talking about design, we should take a look at how Kent Beck and Alan Cooper, as respective though leaders in each space, view this.

Cooper doesn’t talk much about creating the requirements to support the daily use scenarios – he proposes moving directly into design of the solution. This differs from the more traditional technique of writing functional requirements to support use cases. Cooper also breaks down design into two components – program design and interaction design. Program design is everything you don’t see. Interaction design is everything you do see.

[...]

Cooper argues that designing the interaction should happen before any code is written. He uses a construction analogy to drive home his perspective – you can’t pour the concrete before you build the forms. Kent Beck, founder of the XP programming philosophy disagrees with the premise. Beck believes that the cost of changing software is low, and the imagery Cooper uses is hyperbole. We touch on, and link to that debate in this post.

Interaction Design Process Overview

I don’t believe that Beck is arguing for “don’t do design” – I believe he is arguing for “don’t do big upfront design that would delay implementation.”  He’s championing the agile values that emphasize creating working software and responding to change.  I can imagine him saying “no one will buy a design, they want a solution.”  Cooper’s point is that create a solution without first understanding how someone will use it, you can’t create a great product.

Program design has many hidden impacts – cost of maintenance, cost to change, and the performance of the solution.  You can have a design (or architecture) that makes everything easier to do in the future – at the cost of delaying the delivery of anything.  Or you can have a design that minimizes the time to deliver the first thing, while increasing the cost to deliver any particular next thing.  Or you can design a solution that falls somewhere between those extremes.

If you say “we don’t do design” you’re lying.  Every solution includes design.  Your team’s design process may be “big and upfront” or it could be a couple sketches on a whiteboard, or some email exchanges.  You may create storyboards and wireframes.  Or design may be the thing that happens right before the programmer’s fingers strike the keys.  Design may be explicit or it may be implicit – but it never “doesn’t happen.”

In the movie Amadeus, Salieri is astounded that there are no rough drafts of Mozart’s compositions.  That’s because Mozart did the design in his head, not because he didn’t do design.  I’ve worked with programmers who’s “implicit designs” were great, but that is the exception, not the rule.

Who Owns Design?

Since design happens sometime before fingers strike the keyboard, the real question is – “who owns the design?”

• You have a product manager developing an understanding of market problems, and prioritizing the problems that should be solved with your product.
• You may have a product owner managing the backlog and clarifying those requirements (problems) for the development team.
• You may have an interface (or interaction) designer or team of designers who are broadly responsible for “how users interact with our products.”
• You may have an architect or lead engineer who is responsible for the “big picture design” of how your product works.
• You have developers and testers who are responsible for delivering your product. [Note: coding without testing is like typing code without compiling - maybe it works, but probably not.]

You may not have distinct individuals with each of these titles – every small team I’ve worked with has people wearing multiple hats.  This is especially true when you have an agile team full of specializing generalists – any given story (or task) may have a different architect and different implementer.  I’ve only worked with one company where the architects are NOT part of the development team.  If your team is set up that way, please comment below – I had never seen that before, and I’m not convinced that it is the best way to organize – what have your experiences been?

Generally, “program design” is clearly owned by the development team – and product managers (and product owners) know better than to specify program design in their requirements.  Neither the lead engineer nor the product manager believes that the product manager is a better programmer – so the product manager better not be specifying program design and mislabeling it as requirements.  Coincidentally, Steve Johnson, at Pragmatic Marketing has a post running right now with a bit of a quiz – is this a req(uirment) or a spec (design)?

Where the line is more blurred is around interface and/or interaction design.  Some development teams have interface designers as part of the team.  Some companies organize with interface design as a “shared service” within the company.  Either approach can be the “right one” – it depends on too many details to make a sweeping generalization.  When the designers are members of the development team, the solution (from a product management perspective) is the same – the “team” is responsible for all design.  When the designers are not part of the development team, the developers have to consume two sets of guidance – “solve this problem” from product management, and “the solution needs to look like / act like this” from the designers.

Collaboration between product management and user experience people is the ideal solution.  The “requirements” and “design” inputs to the development team are comprehensive and consistent.

Design-Free Requirements

There are benefits – especially when being agile and minimizing documentation – to delivering requirements and design at the same time.  Just don’t do it by embedding design constraints within the requirements.

• When people on your team misinterpret design as requirements, they are unnecessarily constrained.
• As a product manager – are you the best designer on your team?  If you’re busy designing, who’s product managing?

This is trickiest when writing use cases – sequencing a set of interactions is interaction design.  That is one benefit of writing a user story instead of a use case.  An approach that has worked well for me with multiple teams is to deliver user stories (requirements) combined with storyboards (interaction design) and wireframes (interface design).  When details are needed (usually when “changing” versus “creating” an interface), screenshots can replace wireframes.  When business processes are complicated, process flows can replace storyboards.

Just don’t embed the designs within the requirements.

Kano Analysis, while initially created to understand customer satisfaction with features, can be used by product managers to better understand customer problems.  I gave a presentation last week for the Product Management View webinar series on Kano Analysis for product managers.

Kano Analysis – The Webinar

You can watch (flash) or listen to (mp3) the webinar (just under an hour) at the Product Management View webinar page for the Kano Analysis presentation.  I delivered the webinar on Sep 23rd, 2009.  Thanks Val Workman for inviting me to join the group and share an hour with a bunch of great folks.  Also, thanks to the people who asked questions, tweeted, and commented on the presentation.  I really appreciate it.

Kano Analysis – The Slides

If you want to flip through the slides to get a feel for the treatment I gave to Kano Analysis before committing an hour to the webinar, you can do so right here (or view the Kano Analysis slides on slideshare.net).

Thanks again to everyone, and if you have any feedback, include it below or on the PMV site.  Several links to other articles about Kano Analysis are in the comments on the PMV page, if you want to do further research.

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:

1. Identify the problems that need to be solved.
2. Explain why those problems are worth solving.
3. 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.

[larger image]

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.

Writing valuable requirements is important.  It doesn’t matter how well your teams execute if they are off building the wrong products / capabilities / features.  The right products and capabilities are the ones that have relevant value.

• Valuable requirements solve problems in your market.
• Valuable requirements support your business strategy.
• Valuable requirements solve problems for your users.
• Valuable requirements meet your buyers’ criteria.
• Valuable requirements don’t over-solve the problems.

Valuable Requirements – Revisiting

A little over three years ago, I compiled the Big Ten Rules of Writing Good Requirements, which ended up with an even dozen “rules.”  The first rule was writing valuable requirements.  Three years is a long time.  Our environment has changed.  Many great insights have come into our neck of the software development woods from many inspired voices.  I’ve personally learned a lot.  My focus has changed from being more focused on product specification (back then) to being more engaged in business strategy (today).  Our audience here has grown ~ 10x since the original rules were published.  My dog has tripled in size.  Perhaps my writing has even improved.

Given that, it makes sense to revisit the topic now.

Valuable Requirements Solve Problems in your Market

I struggled a little about starting with “strategy” or starting with “the market.”  Pragmatic Marketing’s Framework (recently updated) starts with the market.  When I first watched the great video, where Jim Foxworthy introduces the updates to the grid, I was a little concerned about that.  Market first, strategy second.  Why not strategy first and market second?  I decided that I was happy with their presentation, since the framework is a tool for product managers.  Product managers usually have responsibility for a market, as a component of their company’s strategy – so the sequencing makes sense for a product manager audience.  Jim also puts it in perspective – their framework is focused on the company’s strategy for attacking a particular market.  I’ll stick with that here too.

To understand what problems are valuable for a particular market (or market segment) you have to approach it from your customer’s perspective.  What are the problems they are trying to solve?

Your customers might be distributors of retail products, who’s business it is to acquire, store, and redistribute small products.  They are in a business where their customers value accuracy, timeliness, and low cost of delivery.  Your customers may value solutions that allow them to more accurately redistribute products (they receive pallets full of items, and then redistribute them a case at a time).  They may value solutions that allow them to adapt to changes in orders with minimal turn-around time.  Or they may get the most value out of cost reductions.  Talk with your customers, listen to them talk about their problems.  When I was working for an enterprise software company years ago, our CEO stressed that he wanted to be solving the problems that keep our customer CEOs up at night.  Find out what those problems are.

The next challenge is in breaking those problems down into something actionable.  If your customers’ biggest problem is cost reduction, how do you solve it?  The first step is to understand where the costs are.  One way to visualize and decompose the problems your customers face is with an Ishikawa diagram (check this out to learn how to use an Ishikawa).

The following diagram shows a decomposition of “The cost of driving is too high” problem:

[larger image]

Now you’ve identified a set of problems that are valuable to your customers.  The Ishikawa can help you make sure you’re identifying problems, not the manifestations of problems.

You also have to understand what solutions are already available to your customers.  If you have a competitor that already offers a very good solution to one of the identified problems, your customers will find less value in a solution from you.

Valuable Requirements Support Your Business Strategy

With a set of problems in hand that are worth solving, you have to figure out which ones are aligned with your company’s strategy.

In the Ishikawa above, one of the problems that car owners face is excessively high payments (on their car loan).  Another problem is that the cost of maintenance is too high.  If your company provides financing products (loans and leases), trying to solve the cost of maintenance problem for your customers is probably out of alignment with your strategy.  Making the financing of a vehicle more affordable (while still profitable for your company) is probably a well-aligned problem.

Your company will also have a strategy for engaging the market – target market share levels, target market segments to penetrate, etc.  You may be trying to become a visionary company with your finger on the pulse of your market – or you may be trying to get mass adoption of your product by solving a very common problem, but solving it better than your competitors.  Your strategy for winning in this market may be to differentiate your offerings by solving different problems than your competitors, or defining a unique market.

Another way to think about alignment with your business strategy is to think about the owners of your company’s strategic goals – your internal stakeholders.  Most projects will fail (or be killed) without internal champions who believe in the ideas.

When you’re aligned with a part of your company strategy,  you’re aligned with whoever is the owner of that component of the strategy, and you’re providing value to that stakeholder.  Sometimes there are many components and stakeholders.  You can adapt some process-improvement prioritization techniques that Roger Burlton teaches to get an understanding of which goals are important to whom.

Valuable Requirements Solve Problems for Your Users

Products are used by people.  People use those products to accomplish goals.  They may be using your product for their employers, in which case they have “practical goals” (finish quickly) that represent how their company’s goals (lowered costs) are realized.  And those people usually interact with other people.  You can quickly build a visualization of who are the users (and indirect users).

[larger image]

You can think of this as an ecosystem of users of your product.  Develop personas and their goals to represent these users.  You can apply the same Ishikawa-based problem-decomposition technique when needed to make sure you’re uncovering the real problems (too many people abandon the sign-up process) and not the manifestations of those problems (users have to click too much).

When your users are not your customers, your users have personal and practical goals that represent their individual contributions to achieving your customer’s goals.  And your users achieve those goals by doing stuff.  You can represent that stuff with user stories or use cases.  The key element is to make sure that you’ve identified the valuable activities, the ones that are required to achieve goals.

[larger version]

The above diagram is used when assessing the completeness of requirements, which is an element of assuring valuable requirements.  If a goal has value, you have to identify the set of user stories required to achieve the goal.  Those user stories therefore have value.  User stories that don’t support a goal don’t have value.

Valuable Requirements Meet Your Buyer’s Criteria

The people who buy your products are sometimes not the people who use your products.  Even when the same person is both buyer and user, that person’s mental model for buying is different from their model for using a product.  If you can’t convince someone to buy your product, it doesn’t matter how great it would have been had they bought it.

Here are the opening soundbites from an earlier article on buyer personas.

• Buyer Persona: If you build what he thinks he wants, he’ll come.
• User Persona: If you build what he actually needs, he’ll come back.

And the closing summary points (it’s a long article):

• Buyer personas make purchases when products appear to address their internal view of what the problems are.
• User personas love products when those products solve the real problems.
• Don’t confuse buyers (who need to buy products to solve user problems) with users (who need to solve their own problems).
• When buyers and users are the same people, acknowledge the buyer-goals distinctly from the user-goals.

There are also several really great insights in the discussion thread – including great comments from Shaun Connolly, Edele Revella, and David Meerman Scott!

Valuable Requirements Don’t Over-Solve the Problems

More is better, right?  Not always.  Sometimes, “more” is a waste.  There are really two ways to think about how much is too much.

The ROI of Incremental Improvements

Because of the law of diminishing returns, the next “more” is always worth less than the previous “more.”  Think of it in terms of improving fuel-economy.  If you have a car that gets 10 mpg, and you drive 100 miles a day, you have to buy 10 gallons of gas a day.  If you improve the mpg by 10 mpg (to 20 mpg), you’ll save 5 gallons of gas per day.  Huge value.  If you improve the mpg by another 10 mpg (to 30 mpg), you’ll save an additional 1.3 gallons of gas per day.  Some value.  Another 10 mpg buys you 0.8 gallons per day.  Diminishing returns.

The cost of achieving “more” is also a factor.  The simplified diagram above shows a linear representation of cost as a black line.  The diminishing returns of value are represented as the red curve.  The optimal investment point is where the two curves are tangent (have the same slope) – marked with the blue circle.  Less investment leaves money on the table – additional investment is done at a loss.

Good Enough is Enough

You don’t need to super-solve the problem.  How much more would you pay for a car that got 10,000 mpg than one that got 1,000 mpg?  If you drove 100 miles a day, the difference between the two (from a value standpoint) is trivial.  Over the course of 100 days, you would save 9 gallons total with the car that had ten times the fuel efficiency.

Why haven’t microwave ovens been getting faster every year? Because the move from a 1-hr baked potato to a 5-minute baked potato is good enough.  You don’t need to get it under 4 minutes.

This is known as satisficing - stopping when something is good, not trying to make it “perfect.”  Additional “goodness” will not result in enough additional sales to justify the investment.

Conclusion

The tagline for Tyner Blain is Software Product Success.  On an elevator, I explain that you have to not only “build stuff right” but you have to “build the right stuff.”  And the right stuff is the valuable stuff.

Define valuable requirements to make sure you’re building the right stuff.

User stories can make requirements management a lot easier.  They shift some of the communication from up-front documentation to ongoing dialog.  That’s the main reason they work so well for agile teams.  And agile teams focus on “what’s next?” instead of an ever-changing “what’s everything?”   The problem is, when those conversations are working well, it is easy to forget to make sure that what you’ve done is actually enough.  Add a small dose of traceability, and you can easily validate the completeness of your user stories.

Three Big User Story Problems

Over the last few years, Alistair Cockburn surveyed a range of teams and identified that they all were facing a similar set of problems.  Alistair proposed using use cases to solve those problems.  The following list of problems is Alistair’s:

1. Designers lack the context of the goal that the user is trying to achieve.
2. The team does not get a early indication of the scope of the project.
3. Alternate user-behaviors are not identified in advance of the commitment to deliver.

We agreed then (and still do) that well developed use cases can be used to address these issues.  Since then, however, we’ve done more analysis of how and when to create use cases and when to create user stories.  The primary drivers of the use case versus user story decision still apply, and should still sometimes point you to creating user stories.

Without the context of goals, and without a notion of completeness, your team just has a haphazhard stack of stories.  Not only will this reduce their motivation, but it will introduce frustration both for the implementation team and the stakeholders – no one will really know when the job is done.  Validating the completness of user stories will allow you to know (and regularly revisit) when you should be done.

When you are creating user stories, you need to be able to address the issues Cockburn identified.  You can do that with traceability, and a very small amount of additional documentation.

User Story Metadata

The cool thing about a well-written user story is that it already has metadata within it that makes tracing very easy.  A well-written user story, using a format based on the work of Mike Cohn (in User Stories Applied), would read:

As a [role], I want to [do something] [with some frequency] so that I can/will [achieve some goal].

If you were to build a UML Class Diagram to show the relationships that are implicit in a user story, you would get something that looks like the following:

[larger version]

• The [role] that starts a user story is the persona (lower right corner of the diagram).  For products with simple market strategies, identification of personas alone is sufficient.  Larger companies and larger products are often trying to address the needs of users in multiple markets or market segments.  Each persona you develop is in a single market segment.  You may organize your segments regionally or by vertical industry or any other strategy that helps you position your product.  You can manage your personas not only as members of market segments, but with a hierarchy of roles.
• The [do something] you identify is the meat of the user story (top center of the diagram) – what the persona is going to do.
• The [with some frequency] element tells your team how often a particular user story will happen.  This can be represented as an attribute of the user story.
• The [achieve some goal] component of the user story provides the context (center of diagram) for why a user will be performing an action.  The user will be performing the action either to achieve a user goal or a corporate goal.  If it is a corporate goal, it will have an internal stakeholder.  Ultimately, there should be an internal stakeholder who is not only the beneficiary of that goal, but also the person who “owns” the market segment in which the persona is defined.  Sometimes, there will be conflicts in goals, commonly between user and corporate goals.  These can also result in conflicting goals between internal stakeholders.

This is what makes things pretty exciting – all of that information is already there, and in your user story.  All you have to do now is leverage it.

Goals and User Stories

The following diagram shows how a use case exists to enable the achievement of a goal.

A user story can exist in the same way, just replacing the use case.  If you want to do a deeper dive into how interaction design and structured requirements work together, you can use the following model instead:

Note that the diagram above introduces a couple additional concepts.  The first additional concept is the practical goal – what the persona is attempting to do because it is the manifestation of a corporate goal.  ”Take an order quickly” is the practical goal that manifests the corporate goal of “Reduce time required to take orders.”  The second concept is that of a scenario.  A scenario is an amalgam of user stories (or use cases) that collectively allow the persona to achieve the practical goal.  We already represent this without introducing the scenario concept by acknowledging that a single goal is mapped to multiple user stories.

The common element in both approaches is a strong tie between goals and user stories.  Focusing on this aspect, you can visualize the relationship as follows:

[larger version]

Note that the acceptance criteria for each user story are called out (so that you can confirm that a user story is “done” and “done well”).  Each goal is achieved by enabling one or more user stories, such that the acceptance criteria are met.  This is the crux of it, so I’ll write it again, but in bold for the busy people who scan this article.

Each goal is achieved by enabling one or more user stories, such that the acceptance criteria are met.

Note also that multiple goals can be supported by the same user story.

Validating Completeness

The important question that many developers (agile or otherwise) can not answer about their project is “If we do [everything we've been asked to do] will we meet our goals?”  This is either a failure in communication of context, or a failure to validate completeness of the requirements.  You have to flip things around and ask “If only these user stories are implemented, will the goal(s) be achieved?”  This is the same process used to validate completeness of use cases – just applied to user stories [Ed: that completeness-validation article was written 3 years ago today.  That's 28 years ago in internet time].

Incremental Overhead

Each user story already identifies the goal(s) it is supporting.  The incremental overhead is to recognize that this is “a backwards view” of goal satisfaction and create a simple table that shows the “forward view.”

You are creating traceability from each goal to each of its supporting user stories – but you’re doing it with a simple table (or list, or tree, or whatever).  You don’t have to manage your requirements in some big messy repository.  If you’re using index cards, consider getting some brightly colored sticky-dots, number them for each goal, and stick them on the index cards to show the relationship.

Then ask the question, for each goal, “Will this goal be achieved if all of the traced user stories (and no other stories) are completed, such that the acceptance criteria are met?”

An added benefit of this simple document is that it markedly improves your engagement with internal stakeholders.  You’ve created another opportunity for them to influence the scope of delivery.  These stakeholders can identify user stories that don’t map to any goals (you can drop those stories), and by identifying incomplete support, you can collaborate to make sure the missing user stories are identified.

The task of updating stakeholders about progress and managing stakeholder expectations just got much easier – because you can report progress in the context of completed user stories (and therefore manifested goals).

Reviewing Cockburn’s Issues

Does this approach address Cockburn’s issues (listed at the start of this article)?

1. Lacking the context of goals.  This approach explicitly emphasizes that context.
2. No early indication of scope.  The combination of completeness analysis and acceptance criteria provides concrete insight about scope.  Note that scope can still change, but this approach is just as effective as documenting requirements with use cases.
3. Alternate behaviors not identified early.  Completeness analysis will highlight when the “happy path” (a.k.a. the normal course in a use case) is not sufficient to achieve the goal.  This is really just a variation of the second issue (not understanding scope), but along a variation dimension instead of a coverage dimension.

Conclusion

There is value in being able to document requirements with either user stories or use cases as circumstances dictate.  Cockburn identified issues that teams face when dealing with decoupled user stories.  His approach of leveraging use cases to solve the issues is perfectly valid.  The approach outlined above, tracing user stories, also addresses the issues.  As a product manager or business analyst, you need to be able to address the very real issues with either documentation approach.

When defining requirements, you always start in the context of a goal – either a user goal or a corporate goal.  You need to be aware of both.  Having a positive user experience is important, and requires a user-centered understanding.  Achieving your corporate goals might be in conflict with some user goals.

User Goals

A user centered, or user-centric approach to developing software is one where you start by identifying the key persona in your target market.  For each of those personas, you identify their most important goals.  You then identify the user stories or use cases that represent the things these people do in order to achieve their goals.  These “things” are manifested as practical goals.  For these activities, you design user interfaces (process, layout, architecture, look and feel, etc) that create customer delight for those users, doing those things.  This is how your product exceeds the suck-threshold (good enough that it doesn’t suck to use your product).

Corporate Goals

There’s a reason your company is creating or improving a product.  It may be to gain market share, or improve profitability, or increase sales.  Whatever it is, there’s a corporate goal that your decisions should be supporting.  The (subset of) corporate goals that are relevant to your product could be communicated in a vision and scope document, that constrains the domain of problems to be solved, and provides nuanced insights into viable approaches to solving them (example vision and scope).

Corporate goals are achieved when customers do things with the products.  These “things” are manifested as practical goals.  For those activities, you document what should be accomplishable and why.

Alignment and Conflict of Goals

Notice that both the user goals and corporate goals manifest in terms of people doing things.  When the person (user) wants to do the same things that your company wants them to do, you’re in alignment.  When the user goals and corporate goals suggest different activities, you’re in conflict.

You can see visually that these worlds collide at the “practical goals” stage  in the following diagram, from an article on combining interaction design and structured requirements principles.

It may be great – when the user and corporate goals are in alignment, the practical goal and associated scenario (activity) are easily defined.  What about when the goals are in conflict?

Vending Machine Example

Last Thursday morning, as I interacted with a vending machine, the idea for this article was dispensed along with my Diet Mountain Dew.  Yes, I know that’s odd.  Move on.

It occured to me that the process of buying a cold, caffeinated beverage can be both aligned and unaligned from the perspective of user and corporate goals.  If you imagine writing a use case for purchasing a beverage from the vending machine, your most important scenario is the one where a person wants to purchase a beverage that is available in the machine.

• User Goal: Get refreshed and vitalized.
• Corporate Goal: Sell a beverage.

I want to buy a Diet Mountain Dew, as a means to realize my personal goal.  The owner of the vending machine wants to realize her corporate goal of selling me the beverage I want to buy.  We’re in alignment.  Our requirements definitions and design decisions will be pretty easy – everything that increases the likelihood of and improves the experience of purchasing that beverage is good.  I put my money in the machine and push the button.

Then it occurs to me – there’s a situation where my personal goals are clearly not aligned with the corporate goals of the vending machine owner.  When there is no Diet Mountain Dew available to be purchased.

Consider the following procedure I’m forced to endure:

1. I view the available beverages that this machine dispenses – Diet Mountain Dew is one of them.
2. I put my money in the machine.
3. I push the button for Diet Mountain Dew.
4. The tiny display on the machine presents a message in taunting, scrolling red LED lights: SOLD OUT.

At this point, I’m faced with a choice – select a less desireable beverage, or request my money back and try to satisfy my user goal in some other way.

Consider an alternate procedure:

1. I view the available beverages that this machine dispenses – Diet Mountain Dew is one of them.
2. I view the ‘current availability’ of Diet Mountain Dew and see that this machine is currently sold out of Diet Mountain Dew.

At this point, I’m faced with a choice – select a less desireable beverage, or request my money back and try to satisfy my user goal in some other way.

The differences in these two possible procedures indicate that there is a conflict between the corporate goal and the user goal.  With the first procedure, the “Sell a beverage” goal is given more importance, because it makes me more likely to purchase a beverage that I don’t particularly want.  My utility is potentially sacrificed, while the owner of the vending machine is just as satisfied.

By failing to tell me that I can’t get what I want, until I’m further invested in the process, I am more likely to purchase something else.  That purchase creates just as much value for the owner of the vending machine, but less value for me.

If the vending machine owner had allowed me to use the second procedure, it would demonstrate that the  owner believed the improved customer experience, while risking the loss of this sale, would encourage me to purchase more over time.  The owner would have been prioritizing the requirements and design that supported the user goal ahead of those supporting the corporate goal – in hopes that my user loyalty would result in better word of mouth (more business from other people) and more business from me over time.

Generalizing User and Corporate Goal Conflicts

In this vending machine example, the annoying procedure is probably the right one – I’m going to treat the “point of use vending of cold, caffeinated beverages” as a commodity product.  This market has a very low barrier to entry, and relatively small problem being solved.  I’m not going to tell my friends about how much I love the vending machines from Joey’s Vending and encourage them to go out of their way to find and use those machines.  Nor will I purchase more Diet Mountain Dew because the emotional cost of the occasional “sold out” scenario is trivially smaller with Joey’s machines.  I would, however, be more likely to buy a Diet Pepsi when I’ve already invested time in the process and put my money in the machine – especially when the alternative is to find a water fountain.  I’m emotionally invested at this point.

However, this experience did jump out at me as one that is worth explicit consideration when defining requirements and designing solutions.  It does come up regularly.

The new iPhone 3GS hardware allows tethering (using the phone as an internet-connection device for your laptop).  ATT (the exclusive carrier for iPhones in the USA) is indicating that they will charge customers an extra monthly fee for this capability, when they eventually allow it on their network.  The user already has a data plan, and the traffic that ATT would have to carry is just “data.”  The user just wants it to work.  ATT, however, may want more money, or may want to limit data traffic on its network – perhaps to improve the quality of service to all customers.  This could be ATT’s corporate goal of “provide better service quality” conflicting with the user’s “increase the flexibilty of how I use my data plan.”  The former would likely influence customer satisfaction (and abandonment) over time, while the latter would influence customer acquisition rates.  Another conflict in goals.

Think about how different goals can lead to conflicting solutions, requirements, and designs.  And tell me when you’re out of Diet Mountain Dew before I’m emotionally invested in the purchase.

Blue Ocean Strategy provides an interesting reactive analysis of companies and markets.  Personas are used to understand your customer’s needs.  Combining the two provides powerful proactive insights when positioning your product for market success.

Blue Ocean Strategy

The book, Blue Ocean Strategy: How to Create Uncontested Market Space and Make Competition Irrelevant, by Kim and Mauborgne, was written in 2005.  The book presents a very compelling way to visualize competition in your market by contrasting the emphasis (or effectiveness) of each company at solving particular problems.  The authors argue that red oceans are competitive markets where companies compete to solve the same problems for the same customers.  Their main idea is that by identifying (and solving) unaddressed problems, you can define a new market – a blue ocean with no relevant competitors.  The “red” in their metaphor implies blood in the water, caused by cut-throat competition.  Their position – by defining a new market boundaries with no competition, you eliminate the blood in the water and give yourself a calm, blue ocean in which to navigate your company.

This is a compelling idea, and has a lot of merit.  The Smarter Product Managers book club (started by Cindy Alvarez) reviewed this book last month, and one conclusion we reached during the discussion is that the examples in the book felt “reverse-engineered.”  I feel that the lack of prescriptive advice from the authors created a sense of “that’s fine, but how do I apply these ideas proactively?”   Some of the examples in the book, like Cirque de Solei and Southwest Airlines, felt very compelling (and are often cited), while others felt a bit more contrived.  Almost as if the authors were searching for data to support their arguments – a big no-no for product managers.

Creating a Blue Ocean Strategy Map

The book presents examples of “mapping” markets based upon the strength of the offerings from companies, along different dimensions.  The following example was created by me (and is used throughout this article), but follows the pattern of analysis described in the book.  This is an unresearched, hypothetical example analysis of the market for vaccuum cleaners – or more generically, floor cleaning products.

 [larger image]

The diagram above identifies seven dimensions by which you could characterize the offerings from each company.

• Breathe Easier / Anti-Allergen – sometimes, people vaccuum their rugs in order to reduce allergens (by sucking up dust), making it easier for them to breathe in their homes.  Vaccuum cleaners work by sucking up air through the carpet, collecting the dirt (that is sucked up along with the air), and filtering the exhaust air (that is expelled into the room).  Different vaccuum cleaners pay different levels of attention to removing allergens during this cleaning process, by (1) getting the allergens out of the carpet and (2) filtering the allergens out of the exhaust air.
• Remove Stains – one motivation to clean your floor is to remove stains.  This is not generally a focus of vaccuum cleaners, but products like the Green Machine do focus on removing stains, while also “picking up dirt.”
• Physically Easy to Use – after back surgery, one of the key pieces of advice my mother received from her doctor was “no vaccuuming.”  When you are young and healthy, you don’t expect vaccuuming to be something that is forbidden by your doctor.  Shoveling snow, climbing a mountain, running a marathon, yes – but vaccuuming?
• Reducing Hassle – Why don’t we vaccuum every day?  Because it can be a hassle to get out the vaccuum, set up the equipment, and actually use it.  When you reduce the hassle involved in vaccuuming, you are likely to vaccuum more often, thereby realizing more benefits from vaccuuming.
• Saving Time – Hassle is not the only barrier to vaccuuming.  If you could vaccuum your house in 5 minutes instead of 105 minutes, you would do it more often.  As a teenager, I used to jog behind the lawn mower, just to get the yard done so I could move on to other things.
• Reliability – While reliability is not a major factor when vaccuuming your house (once), it is a key component of making purchasing decisions – because you don’t vaccuum just once.  The more you vaccuum, the more you care about reliability.  This is also an indirect cost factor – a vaccuum cleaner that has to be frequently repaired or replaced will cost more per year than one that has the same purchase price and is more reliable.  This is also an indirect hassle factor – you may delay vaccuuming your home until you can make time to get a broken vaccuum cleaner repaired.
• Avoiding Cost – A direct focus on cost is primarily driven by purchase price.  Other factors (like reliability, and the cost of replacement bags or filters), but people place greater emphasis on purchase price when thinking about cost.  Consumer Reports and other “product review” companies will often “do the math” for you, taking into account all of the post-purchase costs to calculate total-cost-of-ownership.

The above diagram, with fictitous values for “Strength of Competitive Offering”, shows the competitive landscape for the vaccuum cleaner market.  One of the very powerful features of this visualization is that the Roomba faces “no competition” from the other companies in three of the seven categories – Ease of Use, Hassle, and Time.  A Blue Ocean Strategy analysis would say that the Roomba has created their own market, with an absense of competition.

This gets back to our insight that the examples felt “reverse engineered.”  The Roomba does have a dramatically different value-proposition, and focused on dimensions that are not addressed by their competition.  So why isn’t the Roomba in the book?  Because they still compete in the red ocean.  Unlike Southwest Airlines, they did not differentiate their offering in a relevant way.  And that’s the problem we found in trying to apply the principles from the book.  

It is not enough to be innovative and differentiated, which the Roomba certainly is, you have to be valuably differentiated.

So how do you differentiate valuably and proactively?  Identify the problems that your customers value, but don’t yet have solutions for.  How do you do that?  With personas.

Personas

Personas represent customers in your target markets.  Markets are not homogenous – different people in your markets value different things for different reasons.  You develop personas as archetypes to represent subsets of the customers in a given market who share common problems.  More concretely, personas share common valuations of shared problems.

To combine persona development with the market-mapping concept from Blue Ocean Strategy, create the same map, but for personas.  Instead of identifying the strength of each company/product along each dimension, identify how much each persona cares about each particular dimension.

 [larger image]

In the chart above, I’ve created 6 hypothetical personas who populate our market:

• Single Parent – the classic superman / superwoman who does everything, including keeping the house clean.
• Housekeeper – someone employed to keep someone else’s house clean.
• Office Cleaner – the person who vaccuums your office at 2am every night and picks up all the empty Diet Coke cans and Twinkee wrappers.
• Kid (Doing Chores) – most kids won’t ask for a vaccuum cleaner for their birthday, but when you child is responsible for vaccuuming, do you want a battle every week because they hate it?
• Homeowner – like the single parent, but maybe without kids, and definitely with fewer responsibilities (and more time).
• Retiree – like the homeowner, but with a lot more time, and a less robust physical condition.

[Note - the above examples are really stereotypes and not personas (there is no research to back them up - they are entirely fictional) - don't fall into the trap of thinking persona development is this easy.]

OK, now we have an understanding of how much importance each persona places on each dimension.  It looks like a mess, for this example, when you try and absorb the big picture.  If you focus on a single persona, you get great clarity about what that type of customer cares about.  Look at each curve individually, then look at them all together.  If you’re thinking ahead, you’ll suspect that the Roomba is perfect for the kid doing chores.  But wait, we’ll come back to that.

One insight we can gain from this messy view of the market is that you can’t create a product that is “perfect” for all of these personas.  You have to target a specific persona, and tailor your product for that persona.

Mapping Personas to Products

Now we have two views of the market, along 7 dimensions.  We have assessments of the relative strength of each competitor’s offering, and we have estimates of the relative importance to each persona – for each dimension.  What we need to do is combine the two.

All of this analysis runs the risk of introducing a notion of false precision - we have a lot of data, therefore it must be accurate.  So our inclination may be to try and do some mathematically refined, scientific analysis.  I suspect that would be wasted effort, providing no additional insights, and risking leaps to the wrong conclusions.  I propose a simpler approach.

The analysis we really care about – which product offering is best aligned with the needs of each persona?  A simple mathematical equivalent of “which curves match the best” is an easy analysis.  By comparing the values from each competitor curve with those of each persona curve, we can create a series of “how good a fit is it?” values.

 [larger image]

Imagine a persona saying “how well does each company’s product align with my goals?”  This “simple math mashup” takes into account both “they succeed at what I care about” and “they haven’t invested in something I don’t care about (at the expense of something I do care about).”

You can see that the Roomba clearly wins with kids doing chores.  The rest of offerings stand out less, but do provide insight.  Now you can easily drive strategic decisions – “we want to be the vaccuum of choice for housekeepers” now drives some obvious emphasis on ease of use and a reduced emphasis on reducing costs.

Improving The Model

My two main problems with the blue ocean strategy were lack of relevance (who cares about dimension X) and magnitude (which dimension is most important?).  The model above addresses only relevance – a focus on target personas.  We can overlay some “relative importance of each persona” data, or just manually focus our efforts on each persona in series.  

The other magnitude challenge is in understanding not just which problems are important in absolute terms (kids care a lot about saving time, but not cost), but in relative terms (kids would trade an hour of time for a modicum of ease-of-use).  Essentially, defining the utility-curves for each persona.  For any but the largest, most saturated markets, I would hesitate to do the utility curve analysis in detail – it feels too heavyweight and un-agile.

Conclusion

The Blue Ocean Strategy book provides us with a visceral tool for visualizing relative offerings from competitors in a given market.  Combine it with the same visualization approach for personas that participate in that market, and you gain insights into which problems to solve next to achieve product success.

A lot of books and blogs and experts tell us to use “The System shall…” when writing requirements.  Read on to find out why that’s not a very good idea.

Ambiguity Is Bad

It is important that when you communicate requirements, you be unambiguous.  That communication may happen through conversation or documentation, or some of each.  

Conversations are most effective when you are face-to-face, and least effective when you’re talking to someone who is 8 to 12 hours out of sync with you.  This is because conversations become infrequent.  The time difference introduces a resistance into your product creation (requirements and design and implementation) process, because it decouples one of these areas from the other two.  You can co-locate requirements and design with a remote implementation team, or you can have your design and implementation teams both working in a different location than your requirements team.  

Remote teams introduce a latency in communication.  When the teams are working with no (or very few) overlapping hours, this latency becomes very large.  Each back-and-forth can take 24 hours instead of 15 minutes – that’s 1% as efficient!

The most effective ways that people have found to reduce the impact of this latency is through documentation – allowing artifacts to persist over time.  Well written documents can capture understanding, will anticipate questions with correct answers, and will be unambiguous.  The ambiguity part is key to improving team efficiency – every ambiguous statement introduces at best an extra back-and-forth (with possible delays), and at worst, an unpleasant surprise at the end of the project.

When dealing with distributed teams, ambiguity in your documents is a killer.  Your reader can’t pop his head over the cube wall and ask “What exactly did you mean by this?”

Language Barriers Can Hide Brambles

It is easy to acknowledge a language barrier when two people don’t share a common language.  What is insidiously dangerous is when two people share a common language, but not really.  There’s a clever joke – “England and America are two countries separated by a common language.”  And it is very true.  As a Texan, sometimes I feel that way about Americans from New England.  Down here, a bubbler is an oil well that needs to be capped.  Up there – it is a water fountain.

When you learn multiple languages, you translate (on the fly) into your original language.  The one exception I’ve heard is if you start dreaming in the “new” language, you aren’t translating anymore.  As our world gets smaller, and teams become more diverse, you become more likely to have someone on your team who is translating as part of communicating.

Translation is another source of ambiguity, both in conversation and in documentation.  In conversation, you can practice active listening or look for other cues that give you an indication that what you said isn’t what she heard.  In a document, either you are introducing ambiguity (causing another clarification cycle), or you are introducing an error in communication – imagine if the translation is “wrong.”

As dangerous and expensive as this can be in general, with a 1% efficient communication channel, it can kill your project.

Shall, Should and Must

In English, shall and must mean the same thing – something is mandatory.  Should means, roughly “it would be a good idea.”  In fact, should is such an ambiguous term, you should never use it in requirements.  I’ve worked with teams that used a MoSCoW rating system before – every requirement was identified as one of “must”, “should”, “could” (don’t not do it), or “would be nice.”  The problem with this approach is that the team is only accountable for the “must” requirements.  At least in practice.

Personally, I’ve always disliked the word “shall” when writing requirements.  First, not everyone considers “shall” to be a mandate – but generally people do.  Second, I’ve always found the word shall to be too similar to should - which is a terribly ambiguous word in a requirement.  Once I started working with global teams, often with “limited” sharing of a common language, I began to get that feeling that something isn’t right, that maybe shall would cause a problem.  Surely must is ok.

This, I realize, is an opinion.

Translating Shall and Must

Around 5 am this morning I had a couple hours to kill and a disturbing notion of what would be “interesting.”

So I used Google’s translation service to translate shall and must into every supported language and back again.  

When I was still programming, we often had to support import and export of data from our products.  A great way to test the importer and exporter was to import data into the product, then export it back out (or vice versa) and compare the (twice) translated version with the original.  If they were an exact match, both the importer and exporter worked.  If not, there was a bug somewhere.  We called this round-tripping.  As an aside – this is a great way to do test-driven development of import and export functionality.

This morning, I round-tripped the words shall and must from English, through 41 different languages, and then back into English again.  Here’s a table of the results (shall on the left, must on the right):

 [larger version]

Here are the facts about what happens when you translate shall from English into each of 41 other languages, and back to English again.

• In most languages (22/41) shall does not translate back into shall.
• Other round-trip results included: will, should, must, to be, point, has, going, and “I”

That confirmed my fears that shall was a dangerous word.  What about must?  I was not optimistic.  I was also undercaffienated.

Here are the facts about what happens when you translate must from English into each of 41 other languages, and back to English again.

• For 100% of languages (41/41) must translates back into must.

OK, that’s pretty irrefutable data.

Conclusion

I don’t really care if you like the alliteration of saying “The system shall share secrets on sign-in”.  

You need to use the word must when writing requirements to avoid ambiguity.