Monthly Archives: January 2007

Informal Use Case Template

Informal Use Case Template

Free Microsoft Word 2003 template for creating informal use cases. This template is built as a form with guiding text and help text. Read how to use it and download it today.

Informal Use Cases

As part of our series on use cases, we included an article on informal use cases. Informal use cases are designed to provide as much information as possible without the overhead formal use cases. An informal use case template is much simpler than a formal use case template.

An informal use case includes a minimal set of header information for administrative purposes, and immediately gets to the meat of the use case – describing what the user (also known as the actor) does.

Informal Use Case Template

This free template (MS Word 2003 – 34K) can be downloaded from Tyner Blain right now. (zipped version 5K)

Template Screenshot

Above is a screen shot of the template as you see it when you first open it in MS Word. The template is created as a form that you can easily tab from field to field, without having to worry about messing up the formatting. When you want to create an informal use case, just double click on the template file (*.dot). This will create a new word document, Document1.doc. When you save the file, it will be a word document (and not a template).

If you want to modify the template to add header and footer information, for example, you have to open it differently. Open Microsoft Word, then open the template file. You’ll notice that the title bar will say “Informal Use” instead of “Document1.doc.” That’s how you’ll know that you are editing the template. All future documents will include any changes you make to the template.

The template is locked, which allows you to quickly tab between the fields (the grey areas in the document) and input information without worrying about changing the formatting of the template. If you want to change the formatting for a single document, just unlock the document that is open. There’s an icon that looks like a little lock in the formatting tool bar. Or you can select Tools : Unprotect Document.

Note that if you unlock the document, the drop-down control for selecting the use case status will not be available. Just relock the document to re-enable the status drop-down control.

Using the Informal Use Case Template

  1. Download the template file.
  2. Double-click on the template file to create a new MS Word document.
  3. Enter your data (field details explained below) into the fields.
  4. Use the key to quickly navigate to the next field.
  5. Save your document. We suggest a naming convention like “UC##.V#.Use Case Title.doc” or “UC##.YYYYMMDD.doc” if you don’t already have a naming convention. Substitute the use case ID and version number (or current date) into the filenames – this makes it easier to organize your files.
  6. Repeat steps 2 through 5 for additional use cases.

There are descriptions in some of the fields (wherever there was room) to remind you what goes in each field. You can also hit F1 to see additional help about any field.

Help Popup

Informal Use Case Fields

The Header section of the template organizes the administrative information about the use case.

  • Use Case ID – This is the unique identifier that you use to reference the use case from other artifacts that you create as part of developing your software product. In a structured requirements framework, use cases support goals and are supported by functional and non-functional requirements. You will use the use case ID to trace between the use case and the goals it enables. You will also trace between the use case and the functional and non-functional requirements that support it.structured requirements framework
  • Use Case Version – The version of the use case can be used to keep track of each draft or revision of the document – but it was intended for something more powerful. We discussed the notion of having evolutionary use cases – where each version of a use case represents an improvement over the previous version. Version 1.0 might be released for the primary actor, in a particular release. Version 2.0 could be released later, with support for secondary actors. You can track this as the following diagram shows:Use Case Version Schedule
  • Status – Everyone uses status differently. A good reason to edit this template would be to change the available status options in the template to match what you normally use. The template has four simple status selections.
    1. Draft represents an incomplete document.
    2. Proposed represents a document that has been completed and is being reviewed.
    3. Approved represents a use case that has been approved by all parties.
    4. Rejected represents a use case that has been rejected.
  • Release – Put the name or ID of the release into this field. This represents the release for which the use case is scheduled. We reccommend scheduling releases with complete use cases and not portions of use cases. You can use the versioning approach described above if needed to manage your delivery schedule.
  • Author – That would be you. Enter the name of the person responsible for authoring the use case.

The Body section of the informal use case template includes the primary content of the use case.

  • Title – The title, or name of the use case. This should be a simple sentence that describes the use case. If someone were to only read the title, she should have a good idea of what the use case represents. All your use cases should use a consistent naming convention, but the one you choose is a matter of style. You may want to use the subject – verb – object approach (“User Reviews Pending Orders”), or a verb – object approach (“Review Pending Orders”).
  • Actors – The people who execute the use case are the actors. Not “Tim” and “Joan,” but rather “Office Clerk” and “Department Supervisor.” You may want to define an actor hierarchy for organizing the actors that are relevant to this product. If you do – the names in this section should match the ones in the hierarchy.
    Actor Hierarchy
  • Normal Flow – This is where the description of your use case goes. The goal here is to write just enough to clearly define the use case. The individuals on your team will have the biggest impact on what enough is for you. Most use cases involve some branching or decisions. The normal flow should not include these “if…then” constructs. The normal flow should include the most-common or most-valuable path through the use case.
  • Alternate Flows – This is where those uncommon and lower-value paths are documented. Imagine a use case for processing invoices. The normal course would describe how pending invoices are handled. An alternative flow might handle how past-due invoices are handled. A second alternate flow could handle customers with credit-balances in their accounts.


The informal use case is a great tool for representing requirements without a lot of overhead. Using a template can help your team maintain consistency in documentation. If you don’t like our free template, create your own, but make sure you use one.

Some great additional reading is Alistair Cockburn’s Writing Effective Use Cases.
We added the ability to rate our articles, to help us know what people most want to read. Please let us know what you think of this article by rating it from 1 to 5 stars. And rate some of our other articles because this will help people who are new to Tyner Blain. If you’re reading this in the feed or in email, come on over to the website and rate a couple articles.

Thanks in advance!

Foundation Series: Inbound and Outbound Product Management

Product Management Class

Inbound product manager or outbound product manager – what is the difference? We’ll look at the overall role, and the breakdown of responsibilities.

Product Manager Role Definition

More often than not, people talk about product managers without the qualifier of inbound or outbound. We wrote an article last spring where we discussed the role of the product manager. Michael Shrivathsan defined the role of product management as being split into six areas:

  1. Market Research
  2. Product Definition and Design
  3. Project Management
  4. Evangelize the Product
  5. Product Marketing
  6. Product Life Cycle Management

For more details on those six areas, check out our earlier article, as well as Michael’s article.

Everywhere At Once

The product manager is responsible for interacting with customers, marketing, and sales teams. This communication helps the product manager develop an understanding of the market. The product manager also researches the market – understanding competitors and existing products. From the understanding he gains, the product manager can identify needs and opportunities.

The product manager then works to turn this understanding of market needs into a set of requirements that drive the creation of a product.

Product managers shepherd the product through its life cycle. Product managers identify how the product will evolve and adapt to changing market needs. The product manager may drive the evolution of the product to compete in additional markets.

Product managers also help prepare the company to successfully sell the product. They define strategies for attacking the target market. They help the sales team understand what the product does, and how to position it against competitors. And they support the sales team in the field.

How do we split this up into inbound and outbound?

Inbound Product Management

The inbound part of of the job focuses on understanding what the product needs to be.
Inbound activities include

  • Understanding the market needs and our capability to meet them.
  • Defining a product strategy to meet those needs.
  • Planning the creation of the product, including documenting requirements.

Outbound Product Management

The outbound part of the job focuses on making sure that the product is a success in the market.
Outbound activities include

  • Defining a go-to-market strategy.
  • Preparing the sales team with an understanding of the product and market.
  • Supporting the sales team in execution with a focus on multi-customer activities.


Inbound product management is more about listening, and outbound product management is more about talking.

– – -Check out the index of the Foundation Series posts for other introductory articles.

Five Things You Don’t Know About Me

stemming at the pecos
Thanks, Harry Nieboer, for tagging me with this.

For folks who don’t read a lot of blogs – there’s a meme going on right now where bloggers list five things that most people don’t know about them. This spreads virally, like the old email chain letters. After you share your five things, you tag five more people.

Five Things

  1. Before I fell off a ladder and tweaked my shoulder, I used to be able to climb 5.11c (really hard rock climbing). Photographic proof.Sehlhorst Climbing. The ladder thing is both true and ironic. I tweaked my shoulder in order to protect…
  2. My wife, with whom I am madly in love. She and my step-daughter Sarah became my family in 2004. To offset the estrogen levels, we added Scout, a male labrador, to our family last year.
  3. I used to be a mechanical engineer, and even authored a few patents in the field of electro-mechanical controls design.
  4. I was a competitive swimmer, and held a couple Georgia state records when I was 12.
  5. I used to be best-known for my jalapeno poppers recipe, and I am an official chile-head (#51?). I even carry ground habanero with me when I travel, to spice up pretty much anything.

Five More People

Tag! You’re it.

  1. Roger Cauvin
  2. Tony Chen
  3. The Cranky PM
  4. Michael Shrivathsan
  5. Adam Bullied

Product Manager Staffing Levels – More Survey Results


One of our readers is working on determining product manager staffing levels for her company. While every company is different, it always helps to understand where our peers are. We do some in-depth analysis of the 2006 Pragmatic Marketing product management and marketing survey to see how other companies set their staffing levels.

How Many Product Managers?

The first thing we want to identify is how many product managers the survey respondents employ. To make this meaningful, we need to review the product manager staffing levels in light of the revenue levels of the companies. Companies often split the strategic product management activities between product managers and product marketing managers. We’ll look at both. To keep things in perspective, in this and every dataset, we’ll identify the number of respondents in each category.

how many product managers
There are a couple interesting blips in the data.

  • Companies over and under $50 million in revenue have roughly the same absolute product management staffing levels, even though they represent a 4X range of revenue.
  • There’s either a huge jump in staffing over the $500 million revenue level, or a large drop-off at the over $1 billion level.

This data only shows absolute staffing levels, and not the staffing levels relative to the number of products being managed.

How Many Products per Company?

We’re combining the product manager and product marketing manager staffing levels for the rest of the analysis.

The survey asked each respondent how many products they managed. We used the averages (by company size) to approximate a generalization of products per product manager. Here’s what we found when we combine the number of products managed with the absolute staffing levels for PM/PMM.

how many products per company

The huge jump in number of products across the $500 million revenue line might be explained by the higher staffing levels. Or it might be representative of consolidation and higher revenue levels per product for the companies with more than $1 billion in revenue.

Relative Staffing Levels

We started this analysis to help a reader do some strategic planning. Part of that planning is looking at relative staffing levels. These relative levels will also help us counter or validate the statistics above.

Product Management vs. Sales

Many product management activities are in support of marketing and sales departments. To stay strategic, we have to remember to leverage the PM/PMM efforts across multiple customers, and not squander them on individual sales calls.

product management vs sales

The companies with over $1 billion in revenue have by far the largest sales and marketing teams, as well as the lowest ratio of PM/PMM to sales and marketing staffs. This may be representative of additional support within the sales and marketing teams, or it might be a red flag that product managers are being stretched too thin.

Product Management vs. Implementation

Inbound product management involves heavy interaction with the implementation team. We define implementation team as the combination of design, development, and quality assurance. For our interpretation of Pragmatic’s data, we combined dev-lead, development, architect, and user interface specialists with quality assurance to calculate our implementation team sizes.

product management vs implementation

With the exception of the smallest companies, there’s a pretty consistent ratio. This also tends to support the premise that companies in the $500 million to $1 billion revenue range have more products than their larger and smaller peers.

It would also be really beneficial to see the break out of development and quality staffing levels within the implementation team.

Development vs. Quality Assurance

Here’s the data for development and quality assurance teams.

development vs quality assurance

Again, relatively consistent ratios, except for the $500 million – $1 billion revenue companies.


There’s actually more consistency in staffing levels than we expected to find. Unfortunately, the processes that teams use, profit models and other factors make it really hard to draw concrete conclusions from the survey data. But the consistency of relative staffing models does help us set expectations or sanity check our staffing decisions.

Check out our previous articles looking at gender-bias in the data, and product manager salary data.

Marketing Truths – Don’t Tell the Developers


Marketing is as foreign to most software developers as flying is to fish. We’ve found a list of ten truths of marketing, and we’re secretly sharing them with the developers who hang out here. Shhh. Don’t tell anyone in marketing.

Marketing 101

John Dodds wrote Marketing 101 For Geeks, where he shares 10 observations about marketing that might make sense to geeks and coders.

Here’s John’s list with our comments:

  1. Marketing is not a department. A great way to segue into the conversation – as an engineer, the first visual I always have of a marketing department is the one from Dilbert (Scott Adams draws marketing people as if they are at a perpetual cocktail party).
  2. Marketing is a conversation.* This is hard for developers. Conversation requires two-way communication. That’s a truth. But good marketing pre-empts questions and answers them. Imagine the reader having a conversation with your copy (marketing materials): “I wonder what this is?” “oh.” “I wonder how we could use that?” “oh. cool.” “where can I get it?”
  3. Simplicity does not negate complexity. A clear, easy to understand message is what coders might call “incomplete,” “over-simplifying,” or “simplicistic.” The secret that marketers keep to themselves is that this clear message is what opens the door – making it possible for customers to (eventually) understand and appreciate the power of a product that might be described with greater complexity.
  4. Think what? not how?. As cool as it might be that your search engine uses a trie data structure, what potential customers care about is the fact that you can search a billion documents in a tenth of a second. This secret seems to be the reverse of a simple definition of geek – “someone who cares about how it works more than what it does.”
  5. Think will not can. Featuritis is the condition of having too many features. Even the swiss army knife eventually became too large to slip in your pocket. We have to focus on what users need to do, and not everything that could possibly be done.
  6. Only you RTFM. Think about the obvious ways to use a product. Intuititive user interfaces have affordances. They don’t require people to read the manual. And the manual should be written to help people accomplish their goals- not as a description of the functionality.
  7. Technical support is marketing. Every touch-point with a customer is a marketing opportunity. Remember, we market not just by purchasing ads and putting up booths at conventions. We market by word of mouth.
  8. You’re not marketing to people who hate marketing. Remember the disdain you had when you started reading this list? Well, we’re not marketing to people who hate marketers. People want to know how to solve their own problems. They want to know how they can use our products to help. And they like the people who tell them.
  9. You’re not marketing to people who hate technology products. The people who get our message are the ones who are technology-agnostic (see #4 above). They neither love nor hate the product. But they love solutions.
  10. Marketing Demystifies. Remember the conversation from #2? As the conversation progresses, we enlighten our customers, and eventualy they develop an understanding of what they can do with our product. And from this, they develop a desire to buy our product.

*John’s original point #2 was really an anti-jargon point. We thought the conversational part of his point should be stressed instead.


Don’t let them know, but we’re on our way to understanding how this stuff works.

Flashback: A Year Ago This Week on Tyner Blain [2006-01-13]


It was software testing week this time a year ago…

Software Testing Series: Introduction


Check out the index of software testing series posts for more articles.

Foundation Series: Black Box and White Box Software Testing

testing classroom

Blackbox tests and whitebox tests.These terms get thrown about quite a bit. In a previous post, we referenced Marc Clifton’s advanced unit testing series. If you were already familiar with the domain, his article could immediately build on that background knowledge and extend it.

Software testing can be most simply described as “for a given set of inputs into a software application, evaluate a set of outputs.” Software testing is a cause-and-effect analysis.

Software Testing Series: Blackbox vs. Whitebox Testing

arm wrestling

Should I use black box testing or white box testing for my software?You will hear three answers to this question – black, white, and gray. We recently published a foundation series post on black box and white box testing – which serves as a good background document. We also mention greybox (or gray box) testing as a layered approach to combining both disciplines.

Given those definitions, let’s look at the pros and cons of each style of testing.

Code Debt: Neither A Borrower…

Loan Application

Code Debt is the debt we incur when we write sloppy code. We might do this to rush something out the door, with the plan to refactor later. Agile methodologies focus on delivering functionality quickly. They also invoke a mantra of refactoring – “make it better next release.” This can create pressure to “get it done” that overwhelms the objective of “get it done right.” Taking on code debt like this is about as smart as using one credit card to pay off another one.

Using Timeboxes to Visualize Pressure

In our timeboxing tutorial, we introduced a framework for managing releases and the amount of work we do within each release. We can apply the same framework to visualize the pressure that makes us consider borrowing against our future to take on a code debt.
Here’s a quick summary of the concepts from that article.

Each unit of functionality that we deliver in a product or release is made up of two elements – the time it takes to make it, and the time it takes to make it right. We can think of this as function and quality respectively. We;ve drawn them as puzzle pieces to show that they are (or at least should be) locked together. When a developer gives an estimate, it should be for the combination of function and quality – not quality alone.

function and quality

A timebox represents the amount of time and money we allocate for a given release. It basically determines the size of the box that we can fill up with our units.


In our article, we talked about the options we have to try and get more “stuff” delivered in a single timebox. One obviously bad option is to decouple the quality from the functionality in order to deliver more functionality.

plan for bad quality

Several people essentially said “No one would ever plan on bad quality – that’s a bad suggestion!”

We agree – it is a bad idea. We were merely pointing out that it is something people consider. Especially managers who’ve never read The Tipping Point, and don’t know about “broken windows.” “Broken windows” in this case is a reference to the downward pressure that is applied to all future development efforts by forcing developers to work on a code base that has a lot of “low quality code.” The idea is that if we skip the quality part enough times, we will eventually stop caring at all.

We also agree that rational people won’t make a habit out of using this approach. However, there is another way we could find ourselves in this situation.

What if our estimates were wrong? In the middle of the timebox, we suddenly find ourselves without enough time / people to finish.

missed estimates

In the highlighted region of the diagram, we can see that the feature on the left took longer than we expected – and it pushed out the red/orange feature. There isn’t enough room in our timebox to get it all done.


We’ve even suggested that maybe the right thing to do is to take a loan against ourselves and incur a code debt.

There are times when incurring a temporary code-debt is pragmatically more useful than delaying a release or a feature in order to polish the code.

Software Product Delivery – 20 Rules?

I’ve also argued against code-debt as a long term strategy, in the comments on another post.

I definitely agree that code-debt builds over time and gets more and more expensive. Plus there’s the risk of the whole ‘broken windows’ problem that Malcolm Gladwell outlines in The Tipping Point. I visualize it like the graph for a cascading diode – you can build up more and more code-debt (or design-debt, as you describe in the link), with its associated performance penalty, until you reach the ‘critical voltage’ and flood the diode. At this point, it becomes impractical to refactor – rewriting becomes more cost effective.

The Agile Dragon

So, we’ve stated that it might be a pragmatically good idea in the short run, and definitely a bad idea in the long run. But how do we crystalize the message that it is risky? With another good analogy.

Another Good Analogy

We owe our thanks to Mishkin for this extension of the “code debt” analogy that brings perfect clarity to the issue.

Last night I was thinking more about the analogy of technical debt. In this analogy, design and quality flaws in a team’s work become a “debt” that must eventually be paid back.


In other words, every time someone asks a team to let quality slide, they are asking the team (and the organization) to take on debt with an unknown interest rate. Which is lunacy.

Technical Debt, Mishkin Berteig

Thanks Mishkin!


Technical debt is very risky. Maybe it is the right call in the short run (but assume it isn’t). It is never the right call in the long run.

The Wisdom of Crowds Prevents People’s Passions


The wisdom of crowds helps us avoid stupid decisions. Unfortunately, it also prevents innovative, passionate, fantastic decisions. Collective Intelligence is collective insipidness. We need to keep the inputs of individuals in the mix.

Collective Intelligence

Collective intelligence is the notion that a group of individuals will be smarter than a single individual. The old adage, two heads are better than one, is extended to mean several heads. Kathy Sierra goes on a bit of a rant about how this (narrowly applicable) idea has been twisted into the idea that mobs are better at designing stuff than individuals.

Design By Committee

Since we’re breaking out the old saws, we should acknowledge that people also have known for a long time that design by committee is a bad idea.

Eliciting and managing requirements requires communication, and prioritization. Both of these involve collaboration. When we collaborate, we risk introducing the negative effects of collective insipidity [If I were collaborating on this article with a group of other people, they wouldn’t let me use the “word” insipidity].

Brainstorming involves collaboration in the requirements gathering phase of a project.

Prioritization also involves collaboration. We can prioritize the ideas from a brainstorming session, or we can prioritize requirements, or the sequence of use case delivery. Basically any process that involves filtering or sorting is a prioritization exercise.
Kathy concludes her passionate article with a great quote:

No matter what, I believe that in our quest to exploit the “We” in Web, we must not sacrifice the “I” in Internet.

So how do we avoid the dillutive effects of the crowd’s concensus?

Dictators Dodge Dillution

One way is to follow apple’s model – have a dictator. As long as the person calling the shots has good instincts, she’ll make good decisions. If she doesn’t, we’re toast. With this approach, we get both the downside (possible bad decisions) and the upside (possible great decisions).Another approach is to allow passion to stand out, when interpreting the inputs of the masses.

Weighted Prioritization

We wrote an article last September with tips to maximize the benefits of brainstorming.

The idea starts with having people vote on the ideas that were generated in a brainstorming session. This alone is a mathematical embodiment of the commonness of crowds. We end up with the lowest common denominator.

We then added the notion of “voting again with a 5X impact” on those items people feel passionate about. This allows the strongly held notions to compete with the universally not-unappealing ones. Read the article for more details.

Bypass Brainstorming

The guys at OK/Cancel are super effective at creating great content. They do it by using idea seeding instead of brainstorming.

In a nutshell, the two of them collaborate with an iterative process that involves creating ideas independently, transferring “ownership” of those ideas to each other, and then improving upon them. Really a novel concept – check it out.


Crowds can be leveraged to prevent mistakes. They can’t be leveraged to create greatness. Crowds serve to filter out the extremes on both ends. There is value in avoiding the mistakes, but the cost of avoiding greatness is too high. Whenever we bring in the crowds, we have to keep the individuals in the loop too.

Usability Sells Software – Word of Mouth Marketing

for sale

There are three main models for selling software. You can hire a direct sales force. You can spend a lot on marketing and advertising. You can let your users sell the software for you, a technique commonly known as viral marketing. There’s a catch with viral marketing – users have to like your software.

Viral Marketing

We wrote an article in 2005, Ideavirus – Marketing By Word of Mouth, where we talked about a presentation by Seth Godin.

Some really key points he makes –

  • The idea vectors from user to user (slide 29)
  • The more you give your idea away for free, the more valuable it is (slides 32-33)
  • Build the mindshare first, then monetize. “get cash now!” cripples the spread of your virus (slides 36-40)
  • Seth gave his book away instead of selling it – 200,000 downloads the first two weeks (slide 55).

Seth may be the authority on viral marketing today. When he combines his work with Malcolm Gladwell, we get a great extension of the idea virus concept:

Seth Godin spells out the virus analogy. Someone uses a product or service and raves about it to his friends and associates. This is called sneezing. Some people only sneeze occasionally. Some people sneeze all the time. Some sneeze quietly, some loudly. Some sneeze to a small crowd and some sneeze to a huge gathering.

Karl Palachuk

Its the sneezers that spread the virus. But what makes people want to share?

Compelled To Share

People want to share the virus when they love the product. Gladwell talks (I think in The Tipping Point, but I don’t have it in front of me right now) about how some people are predisposed to sneezing. They will tell us all, good or bad, about the products that generate enough emotion for them to feel compelled to spread the word.

This sounds pretty scary – customers telling everyone about our product. What if our product sucks?

BazaarVoice, a company in Austin, issued a press release a while ago – “Positive Online Reviews Outweigh Negative Reviews 8 To 1.

Analysis across a diverse set of products and services indicates that positive reviews outweigh negative reviews 8 to 1, with an average rating of 4.3 out of 5 stars across all live Bazaarvoice clients.


“We are seeing a ‘Rating J-Curve’ across many clients in diverse industries,” said Sam Decker, vice president of marketing and products at Bazaarvoice. “The distribution looks like a J on a graph, where you see a low volume of 1 star reviews, fewer 2 and 3-star reviews, and a huge jump in 4 and 5-star ratings. While surprising at first, this finding agrees with third-party studies that suggest word of mouth is much more positive than we often assume.”

Sam Decker (Who also has a great blog)

If you’re still gun-shy, even though we know the odds are in our favor, there are ways to make our software not suck.

Comprehension Through Contrast

There’s a great visual in an article at 37signals titled In-store good or at-home good? that puts this all in perspective, when compared to traditional marketing approaches. The article sites an analysis from the Harvard Business Review.

They contrast the imact that the number of features has on two different personas. The buying persona, and the using persona.

  • The buying persona perceives more value (at the time of sale) from having more features.
  • The using persona experiences more value (over time) from having fewer features.

This is the basic premise of the more is less argument. We can step back and generalize this a bit.

Software that is more usable grows in value to users over time

Usability Sells Software

The buying persona is the target for marketing and advertising. She is also the person that a direct sales force tries to convince to buy our products. That’s why marketing is always asking for more features. They want products that appear to be more valuable, because perception sells.

But buyers aren’t sneezers. Rarely does a friend call and say “I just bought this, and I haven’t used it much, but you have to get one!”

The idea virus is vectored by users. And users grow to like the product more and more over time. And the usability of the product has a major influence over how well they like the product. The more usable it is, the more word of mouth marketing we get.

Why Requirements Approval Matters and How To Make It Easier


Getting requirements documents approved can be a pain in the butt. Why do we need to do it in the first place? The approval process is more than just reaching concensus or creating a contract. Done correctly, it presents an opportunity to get more inputs from stakeholders.

The Approval Process

On the surface, the approval process is pretty simple:

  1. Write document
  2. Review document
  3. If changes are required, go to step 1
  4. Approve document, reject document, or approve document “with minor changes”

Collaboration And Approval

However, this simple process can become more complex when multiple people must collaborate and approve. Consider the following thumbnail of a real-world approval process:

approval process

This process shows what happens with only two approvers / collaborators.

  1. Person A reviews the document, and we might make changes.
  2. Person B reviews the updated document, and we might make changes, causing us to send the document back to person A.

There are two approaches to dealing with multi-party approvals: do them in parallel, or do them in series. When multiple approvers are reviewing a document with similar criteria, parallel processes work best. When the approvers are interested in different elements of a document, a sequential approach may be more efficient. For example, the business owners will care more about requirement correctness, while the implementation team will care more about requirement completeness. One person has a business context, while the other has an implementation context.

Benefits Of Approval

We do get some serious benefits from eliciting approvals from our stakeholders:

  • Course Correction. Feedback that we are headed in the right direction. Maybe our documentation skills need work, maybe the solution / goal / opportunity is a moving target. By getting regular feedback and approval, we can nudge the tiller to keep us on course. This is a key tenet of incremental delivery, where the feedback is based on each iterative release.
  • Coverage of Context. We usually have to collect inputs from multiple people to gather complete requirements. These people have different perspectives on the requirements, goals, or processes we are documenting. Getting the multiple inputs, and resolving conflicts of perspective helps. Each interviewee will identify “missing” requirements relative to the other interviewees. Different stakeholders will regularly disagree about requirements. We have to resolve those differences, and getting approvals from the stakeholders will help explicitly manage expectations and document concensus.
  • Corporate Closure. Executive oversight is important for large projects. Some execs will get into the weeds and review documents themselves. Usually, they will delegate, such that each of their departments is represented in the approval process

These benefits all help us prevent mistakes and ultimately reduce costs. They can also help a project navigate the murky waters of office politics. “If So And So approved, then this must be worth looking into…”

There are also costs to getting approvals. Primarily, approvals slow things down in the short term (always), and can potentially slow things down in the long term. Most of the time, the benefits outweigh the costs. If the process is painfull enough, the costs will outweigh the benefits.

Process pain comes from delays and inefficiencies introduced into the process. Even with good requirements documents, there are some personalities that make the approval process at best tedius and at worst untenable.

Approver Anti-Patterns

A pattern is a model for doing something in a repeatable way. Object oriented programming brought patterns to the forefront as a way of “standardizing” architectural approaches to solving common problems. Over time, people developed the notion of the anti-pattern – a pattern for doing something the wrong way.

Here is a list of the archetypes of problem-people we’ve seen:

  • The Rubber Stamper. Someone who’s approval provides as much value as the effort that went into approving. Sometimes people are too busy, too checked out, or too far removed from the content of the document to be able to provide valuable input. When they stamp their approval without spending the time to truly review the document, they add no value.
  • The “I Don’t Get It! I Don’t Get IT” Guy. Remember Big? John Heard played Paul, the rival designer at the toy company. He brings a bunch of emotional baggage into a product design review meeting, and undermines the effectiveness of the group at evaluating the ideas on their merit. Sometimes people are unprepared to review a requirements document. They can quickly absorb a lot of other people’s time as they try and get up to speed. In the mean time, they will do more harm than good by spouting off.
  • Johnny Come Lately. Some requirements documents fade and yellow and curl at the edges under a layer of dust before they ever get reviewed. When people pocket veto a document, they hurt the schedule. Sometimes, they do it on purpose.
  • The Flip-Flopper. Ever gather requirements, only to have your source go schitzophrenic on you and completely reverse their position when it comes time to formally approve a document? We might record the information incorrectly, when our elicitation techniques fail us. But flip-floppers will fail us even if we capture the information correctly.
  • The Pedant. The goal of a requirements document is communication. One challenge in writing those documents is avoiding ambiguity. Editing a document for clarity is good. Wordsmithing a document to make it read precisely the way someone wants can be bad. The pedant will spend time on “that” vs. “which” and “aluminium” vs. “aluminum.” The time spent on these valueless edits can’t be justified.

Making the Approval Process Easier

Here are some suggestions about how to reduce or eliminate the problems that arise from the anti-pattern reviewers:

  • The Rubber Stamper. Get this approval off the list. There’s no point in spending time tracking and gaining a meaningless approval.
  • The Obnoxious Guy From Big. Also known as the unprepared guy. If folks haven’t reviewed the material on their own in advance of a review meeting, cancel the meeting and reschedule. If the “reviewers” aren’t ready the next time, cancel again. Their behavior corrects pretty rapidly.
  • Johnny Come Lately. To quote a manager I worked with – “Pursue, but don’t pester.” Stay on top of people with visits if possible and phone calls if not. The immediacy of your presence combined with the annoyance of being constantly harangued will achieve results.
  • The Flip-Flopper. We can usually dampen the oscillations of someone’s revesing opinion with a short one-on-one conversation.
  • The Pedant. Helping the pedant understand the context for the document is a great place to start. Then coach the pedant in the fine art of writing requirements, and the need to balance perfection with realistic completion times.


Getting approvals is important. Preventing common approval-problems will make any team more efficient. Hat tip to Kupe for getting us thinking about this one.