Six Requirements Models For Agile Projects

When working on any agile project, most people will agree there is still a need to understand requirements. With the quick iterations of these projects, it’s more important than ever, to use visual models to capture the requirements. When done correctly, they are easier and quicker to create and understand than a list of written requirements. Selecting the appropriate models will vary by project; however, we can suggest a few common choices that work well.

High Level Models
At the beginning of the project, it is important to get a quick picture of the breadth of the project. This picture will help the team determine where to dive for depth. It is really important that these models are done as broad strokes, with just the bare minimum information. To get a sketch of that big picture, consider these models:

• Context diagram – This diagram simply sets the landscape of the project, clearly indicating the scope boundaries.

• Org chart – This is a model that often already exists in the organization. It can quickly help identify all the possible users or user groups that should be included in the project discussions.

• Data flow diagram – This is a quick sketch of the key pieces of data flowing through the system, including where it is created, changed and deleted. The data in this diagram should only be data that is important to the users of the system. They will help to identify the most important data and systems to work with.

• High-level process flow – Let’s start by saying this is nothing fancy or complex. The flow diagram should describe the major obvious steps. Again, the purpose is to sketch it simply, to give the big picture. In no way is it meant to be comprehensive or detailed.

Imagine one of your iterations requires bringing in new users to the team. These four models will give them an opportunity to quickly see the big picture of what this project is and where it is going, without having to read a 200 page spec (since there isn’t one!). You can also use them with your users to prioritize the most important pieces of the system for the iterations.

Models in the Iterations
Once you have prioritized the work for the first iteration, the two most popular models are likely to be:

• User stories – You can write these for the most important parts of the flow. They will be less detailed than the traditional use cases, supplying just enough depth to be developed.

• Wireframes – These will be connected to high-risk user stories, when sketching an interface might be a good aid to help the users explain what they need. These should be done in a quick modeling tool, or just by hand.

There will be other models. Sometimes you won’t even use these. The common theme in all of them is to create a visual representation of the requirements because it is faster to create and read. And with them all, only do the bare minimum necessary.

Four Ways To Improve Agile Requirements Management

One of the challenges of Agile projects is ensuring that the requirements remain “Agile”. While requirements are not necessarily neglected on Agile projects, an Agile project may erroneously take a waterfall approach to requirements.

Here are some simple techniques to adapt your requirements management effort to an agile project. The quotes at the beginning of each section are from the “Principles Behind the Agile Manifesto” at http://agilemanifesto.org .

1. Communicate Requirements Often And Effectively

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Two problems with email is that it is inefficient and easy to ignore. Email thread discussions can be long, tedious, and annoying. Despite the advances in emoticons over the past several years, it is also impossible to interpret non-verbal communication in email.

Resolutions to discussions around requirements, scope, and implementation will be resolved much quicker and to the satisfaction of more stakeholders through a meeting or hallway conversation.

If moderating a large number of email discussions is part of your current requirements process (for example, after the initial draft of the requirements doc is published), perhaps it’s time to schedule regular meetings at key points during the release cycle.

Established method: Email discussion

Suggested method: JAD, daily stand –ups

2. Use Collaboration Tools For Requirements Management

“Business people and developers must work together daily throughout the project.”

This is related to the other “C”—Communicate.

Communication on a project should be visible to all stakeholders in the project. Changes to requirements should be pushed out quickly and universally, without having to remember whether the developer who started last week is on the dev@mycompany.com mailing list.

Manage requirements in a central location where all stakeholders have immediate and easy access. An internal website for requirements and product management information is a much more efficient way of reaching your audience than emailing copies of documents to your stakeholders.

If possible, include collaborative tools like wikis and discussion boards as part of your website.

Established method: Word documents attached to emails

Suggested method: Wiki/Web page with automated change notification

3. Add Models And Wireframes To Your Requirements

“Continuous attention to technical excellence and good design enhances agility.”

If applicable, use wireframes or mockups with callouts as a supplement to your requirements.

This is especially useful on projects which call for enhancements to existing interfaces. A wireframe with brief text descriptions is easily consumable, and conveys a large amount of information very efficiently.

Include more detailed descriptions of wireframes and mockups in your user stories, and publish it on your internal product management website (see #2 above).

Established method: Design document/specification; Text-only documents.

Suggested method: Internally-hosted website with wireframes and bulleted descriptions

4. Keep User Stories Simple

“Simplicity--the art of maximizing the amount of work not done--is essential.”

Ensure your user stories describe one and only one feature, and only the functions necessary for that feature.

Looking through a large, monolithic document which describes multiple features to be implemented across several releases wastes time.

Breaking your user stories down into descriptions of the most basic functions required for a feature also helps maintain release discipline.

Resist the temptation to include requirements for “nice to have” or “future” functionality. This clutters the user story with unnecessary information.

Established method: Large document which describes many features

Suggested method: Wiki page/website with a single page devoted to a single feature. Include links to related features.

ProductCamp Austin Is Almost Here!

ProductCamp Austin is coming in a couple of weeks - it's a "collaborative un-conference/workshop on Product Management and Marketing topics."

It's free to attend!

Seilevel will be sponsoring the event and offering up a volunteer to photograph the event! We'll put the pictures on Flickr for everyone to see after.

My personal thought about it all - Austin has a lot of outstanding people in the space of product management (anecdotally evidenced by the fact I read more product management blogs written by people in Austin than anywhere else!). This event is a place to get those minds all in one place and have really interesting discussions! Unfortunately I'm unable to attend as I'm going to be on my way to the International Symposium of INCOSE 2008. However, I encourage you all to attend and write about it after!

Your Requirements Best Practices Are Not Your Reality

To begin with an analogy: I have a friend that can be unreliable sometimes and show up late when we have plans to meet. This is especially difficult to manage when we are meeting to see a movie – if she shows up 30 minutes late, then the movie date is off because the show has already started by the time she gets there. She’s a great person to be around, just difficult to manage at times. We agree that we need to meet 15-30 minutes before the show time (best practices), yet something happens and she shows up after the movie starts.

If our plan to see a movie was instead a project for which I was the requirements expert and she was the project lead, then the concept of showing up 15-30 minutes before show time would be a recognized best practice. So what to do when an acknowledged best practice conflicts with what the project lead wants (the right to show up late in the case of the movie example)? The lead wants the benefit of the best practice (seeing the movie), but things happen or constraints are in place that create a situation where this cannot be done.

What I should do (Best Practices) ≠ What I’m going to do (Reality)

The first step I take in these situations is to first fully understand the project lead’s reasons for not being able to apply the best practice. From the movie example: perhaps my friend is taking college classes at night, and they end right before the movie meeting time. In that case, we could just meet for a later movie, or wait until the weekend. Can the lead and I find a “movie time” that works for everyone where we can still apply the best practices?

In the very rare case that the project lead is simply in disagreement with the use of the best practices, then I determine if it is something worth arguing for. How will the project be affected if we do not apply the best practices in question? If the impact is minimal or can be easily negated and/or managed, then it makes sense to apply the practice that the project lead is requesting. If the impact is too great to ignore, then I work to convince the lead to trust me and let me demonstrate the benefits of applying the best practice.

By the end of the project, we are laughing and munching on the last of the popcorn together as we exit the theater.

Is Your Halo Blocking Your (Requirements) Vision?

There is a correlation between projects that meet documented needs (but not the business needs) and the ‘Halo Effect’.

The Halo Effect, as defined by the American Heritage Dictionary, is "an effect whereby the perception of positive qualities in one thing or part gives rise to the perception of similar qualities in related things or in the whole". More practically speaking, it is when someone who is an ‘Expert’ on a subject area is appointed as the project manager because of that expertise. However, being a Subject Matter Expert (SME) does not automatically make someone a Good Project Manager.

One of my first project management experiences came when I had asked our company to address a customer service issue that was affecting the operation of my department. Being the person closest to the problem, I was assigned as the PM and sent on my way.

I started off listing all of the things that I thought were requirements in as much detail as possible. I then had my team look at everything and off we went. The project team worked really hard and we completed my project on time and on budget.

Once completed, the problems started. We were only able to address part of the original issue that we set out to fix. We had fixed my side of the problem. The rest of the issues were still there. I was appointed to the PM position because I was the expert, but that ended up hurting the project. I had failed to get other experts involved because I thought I knew it all.

While I have learned my lesson, I have seen this same scenario play out over and over again. Time after time, subject matter experts are put into PM positions because they know “what’s best”. Many times the projects requirements turn into being all about the SME’s opinions rather than company needs.

The next time you think you have it all figured out, perhaps you should stop and make sure to evaluate whether or not the full realm of expertise had been explored". It just might make a difference.

This is Going to Bite You

Unfortunately, many of us have been in situations where we are asked to produce work that is not up to our quality standards. Typically this is because of deadlines. We know that a lack of quality will cause us problems now (documents that are hard to understand, possibly misinterpreted, and documents that are hard to maintain). We’re also concerned about the foundation we’ve created for the next iteration of the requirements. We know it’s wrong, and may even argue against sacrificing quality with statements like “this is going to bite you in the future”.

Need a more tactful argument? Scott Sehlhorst’s article Code Debt: Neither a Borrower… is a great discussion on the cost of sacrificing quality in a development effort; the lack of quality is a debt you will eventually have to pay back. Although the article focuses on pressure to deliver code without quality, the points apply to requirements as well.

Scott summarizes with a great quote from Mishkin Berteig’s article Technical Debt: "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."

Give these articles a read; don’t get bitten.

Why Should You Use Requirements Models?

Why should you use requirement models? Isn't it faster to just start listing the functional requirements? In this post I'll explain why you shouldn't do that - and why requirement models are so powerful.

Provide Context
You cannot pick up a list of 500 system shall statements and quickly get a grasp of what the system needs to do. Higher level models, such as System Context Diagrams, Entity Relationship Diagrams, Process Flows, and Organizational Charts are great ways to understand the complete picture. Other models can provide important contextual reference for developers, testers, and others that need to consume the requirements (Use Cases are great for doing this).

Help Derive Requirements
Models can help you generate requirements quicker than you could than without them. Use Cases are a great example of this - once you've generated the series of interactions, it is relatively easy to examine each step and ask the question "what does the system need to do to support this step?" Likewise, you can examine interfaces within a System Context Diagram and start thinking about what requirements are necessary to support them.

Prevent Missing Requirements
Going back to the proverbial list of 500 system shall statements - it is nearly impossible to look at a list like that and determine if anything is missing. There's a post here that describes this in more detail.

Easy to Utilize
Most models are easy to read and use. If you've ever had difficulty getting stakeholders or end users to review your 200-page document (and who doesn't love to read those!?), consider leveraging models to shorten the review time. It's a lot easier for someone to validate requirements while using a Process Flow or Use Case than it is without them.

So avoid the temptation to jump straight into the requirements - your requirements will be more complete, have more context, and will make it easier for others to validate and use your requirements.

A 2-year old can do this

I was driving somewhere with my 2-year old daugther the other day when she started asking me questions. More specifically, she asked me one question, "Why are their no clouds today?" I quickly gave an answer, and (those of you with kids know where I'm going with this) she proceeded to follow up every answer I gave with, "Why?" It forced me to really get to the root of what we were talking about (and recognize the limits of my knowledge of cloud formation. :) However, I also realized that a 2-year old would make a great Business Analyst! One of the fundamental rules of elicitation is to ask "why?" Keep asking "why" to get to the bottom of whatever topic you are discussing with a SME, and you'll almost always find out what the real issue is. In addition, you will gain a deeper understanding of the topic being discussed. So if you ever find yourself at a loss for words when eliciting requirements, just remember to act like a 2-year old.

Know Thy Product

I read a post recently in the Austin Product Managment Yahoo Group stating that Product Managers should not know their products. The author's theory is that PdM's who know their product will not be able to effectively manage their product.

"In a nutshell, the more product knowledge you have, the less product management you're doing because your product knowledge gets you sucked in to a plethora of non product management issues."

I disagree with his underlying premise that product knowledge and product management are incompatible. I think a good product manager does need to know their product, but as important, they need discipline. As it turns out, the author partially agrees with me.

"Product managers need to know their products, but not so well that they mortgage their ability to lead others, influence key decisions and articulate value."

However, he appears to believe that once a PdM has too much product knowledge, the discipline needed to perform the duties listed above is lost. While it may make being a PdM harder, it doesn't make it impossible. In the end, a PdM with strong knowledge of their product and discipline to excute their responsiblities is a winning combination.

Bridging The Gap: Best Practices In Translation For Business Analysts

Requirements analysts often play the role of translator. They listen to, understand, and document the needs of system users in the users’ natural language and they present the users’ needs to system designers and developers in a more formalized ‘language’ made up of models and other artifacts. It is critically important to project success for the analyst to communicate effectively with both audiences.

Most analysts do this without really thinking much about it or examining the process and the best analysts do it quite well. But translation is actually a complex undertaking and it’s worth spending some time on it to understand what is really going on and exploring for ways to improve the process and the results.

Know The Requirements Process

The simple description of the translation process involves just two steps: Decoding the source content and re-encoding the meaning of the content in the target language. A more in-depth look at these two steps reveals some significant complexity. Translating from one ‘natural’ or spoken language to another requires that the translator understand the syntax, grammar, and nuances of both the source and target language. This is a much more involved process than simply taking one word at a time from the source and finding the equivalent word in the target.

For requirements analysts the task has a further challenge in that the target must be precise and rigorous while the source will usually contain vague and indistinct literary constructs that are normal in the everyday use of a spoken or written natural language.

Know The Language Of Your Target Audience

I could not find any research on translation specific to the work of requirements analysts, but there is a fair amount of evidence that deep knowledge of the target language is more important for a translator’s success than expert level fluency in the source language. The research suggests that while perhaps coding experience is not necessary, it is important for RAs to have extensive knowledge of the models used in requirements specification and this knowledge should be from the perspective of the consumers of the specification, designers, developers, testers, etc.

Research and best practices from the translation business also suggest that the draft translation should be reviewed by a second translator with deep knowledge of the source language.

Many software requirements analysts do have a background in software design and development but many come from other disciplines as well.

The ideal situation may be for the requirements specification to be first drafted by an analyst with deep knowledge and background in software design and development and then reviewed by an analyst with deep knowledge and background in the business. Not every project team will have access to the ideal mix of analysts but if your project does it may be worth a try.

Good Faith

Let’s say you take your car in to have it worked on and you get a $1000 estimate and are told you have to leave it for 2 days to get the repairs. It turns out that once the repair shop opens up the engine, they find out the cost is an extra $500 and it will take another day. Here are two possible responses:

• Repair Shop A. The repair shop calls as soon as they find this out and lets the customer make an informed decision about how to proceed or abandon the work.



• Repair Shop B. The customer shows up at the end of day 2 to pick up his car, and he’s told his car is not ready, sorry, and, by the way, you’ll owe an extra $500 when we are done. Or, you can take it today, but it won’t work right. Regardless, you owe use $1000.

As a customer, I’d readily consider going back to Repair Shop A. They made a mistake in the estimate, but they kept me informed and gave me options. I’d feel they acted in good faith.

On the other hand, Repair Shop B would never see me (or my friends) again. I’d feel they were unprofessional and acted in bad faith.

Yet, I see this happen in development all of the time. There are situations where the development team has control of the schedule: their estimates are accepted and scope is controlled to allow development to complete in their estimated time frame. The development team does not report any problems or schedule issues during development. However, when the software reaches code complete and is turned over to the quality assurance team for testing, it is a frightening mixture of buggy and undeveloped features.

Why don’t developers understand they are acting like Repair Shop B? That they are acting in bad faith when they do this, and that their credibility is damaged? Again, the problem is not that they made a mistake in the estimate; it is how they handled it.

I wish I had a solution to this. I realize situations like this are usually complex and perhaps loaded with baggage. Right now, I’m hoping that my analogy will help developers understand the consequences of such actions are not only to the product they are producing, but also to how others view their credibility. Act in good faith.

Don't Forget About the Testers

"Karl - how's testing going on Project Zeta?"
"Not too good, Michael. I can't figure out which features have been implemented, it looks like several key requirements have changed but I don't know what the new details are, and I have a whole slew of untestable requirements."
"Some of those 'the system shall be available for 99.9% of the year' requirements?"
"You got it. The requirements team makes it so hard for my group to do our job - and that's on top of our testing time always getting reduced!"

I've changed the names to protect the innocent, but conversations like this happen all the time. As Product Managers, we produce requirements for all of our stakeholders - and that includes teams like training, development, and testing. I'll give you three simple pointers to keep in mind that will make your test teams your best friends.

Make Requirements Testable
Easy, right? Then why is this still a problem for so many people? Part of the problem is that we take statements like the one above (about availability) at face value as valid requirements. We need to probe and explore to find out the real reason behind the statements (and therefore the true requirement). Include someone from your test team in the review process and specifically ask them to highlight requirements that are untestable or risky - and work to resolve those.

Setup Traceability
Karl can't tell which features are implemented probably because traceability hasn't been setup. Go here for details on how to do traceability (and why it is so important).

Maintain Good Change Control
Requirements change. If you aren't setup to deal with this fact, your project will suffer for it. Make sure that when things change downstream teams are made aware of the change. I won't dictate how you do this - your internal organization and development methodology will determine this - just make sure you have some kind of process in place that everyone understands and follows.

Keep these suggestions in mind and your testers (and Karl) will thank you!

I Hate to Wait

Ruby-throated and black-chinned hummingbirds have been gone from the U.S. since last October. It's now Springtime, and I'm waiting for them to migrate back from their 6-month vacation in Mexico and parts of South America. The waiting is killing me! I hate to wait. But, there are things that I do each spring to prepare for their arrival, things that make the wait a bit easier to bear:

I buy a big bag of white sugar. I mix my own hummingbird nectar - 4 parts water to 1 part sugar.

I clean all of my feeders, fill them with nectar and hang them out in the yard.

I tie long pieces of red ribbon or red surveyor's tape to bushes and trees in my yard - hummingbirds are curious, and if a fluttering bit of red catches their eye, they'll probably come investigate.

I pester people I know to hang hummingbird feeders in their own yards.

In my professional life, I don't like waiting much either. Especially when something almost as exciting as hummingbird arrival is about to happen - the start of a new project! There's often a waiting period for the Analyst that occurs while contracts are finalized, budgets are approved, and client counterparts prepare for you to show up on site and start working. That waiting period can be difficult if you're impatient, like me. But there are things you can do to make the wait less painful - ways to prepare, even though you can't quite start in on the real work:

Do some research. Get hold of any existing documentation from the client, if you can, and read it. Search for information on the internet about the project domain - will you be working on medical billing software? Financial stuff? Familiarize yourself with wacky acronyms now, and you can sound competent when you start meeting with SMEs.

Get organized. Start coming up with topic areas for which you may need to gather requirements. Try to get a list of SMEs, and find out what their roles are in the client's organization. If you need to have the washing machine repaired, the cat "fixed", or want to take a couple of days vacation - do it now!

Buy new supplies - personal and for use during elicitation sessions. Need a new laptop battery? Whiteboard pens? Colored sticky notes? Giant pads of paper for SMEs to draw on? Stock up now and you'll be able to hit the ground running once the project kicks off.


So, what are you waiting for? Think of some things that you can do today in order to prepare for tomorrow. Or next week, or next month. And while you're at it, pick up a hummingbird feeder, a bag of sugar, and get that thing out in the yard! If you're lucky, you'll get to watch hummingbirds dive-bombing each other all summer long.