Skip to main content

Author: Ellen Gottesdiener

Agile Requirements: Not an Oxymoron

May10_Ellen_croppedAdult children. Jumbo shrimp. Seriously funny. I’m sure you recognize these expressions as oxymorons-self-contradictory phrases, often with an ironic meaning.

Should we add “Agile requirements” to the list? Does Agile development fit in with traditional requirements practices? And if so, how?

Once More into the Breach

Traditionally, defining requirements involves careful analysis and documentation and checking and rechecking for understanding. It’s a disciplined approach backed by documentation, including models and specifications. For many organizations, this means weeks or months of analysis, minimal cross-team collaboration, and reams of documentation.

In contrast, Agile practices-Lean, Scrum, XP, FDD, Crystal, and so on-involve understanding small slices of requirements and developing them with an eye toward using tests as truth. You confirm customers’ needs by showing them delivered snippets of software.

However, Agile projects still produce requirements and documentation, and they involve plenty of analysis. On the best Agile projects, requirements practices combine discipline, rigor, and analysis with speed, adaptation, and collaboration. Because software development is a knotty “wicked problem” with evolving requirements, using iterative and Agile practices is not only common sense but also economically desirable.

Indeed, Agile requirements drive identifying and delivering value during Agile planning, development, and delivery.


Agile teams base product requirements on their business value-for example, boosting revenue, cutting costs, improving services, complying with regulatory constraints, and meeting market goals. If you’re agile, it means that you focus on value and jettison anything in the product or process that’s not valuable.

Planning covers not only the “now-view” (the immediate, or iteration) but also the “pre-view” (the near term, or release) and the “big-view” (longer time horizon, or the vision and product roadmap), with close attention to nonfunctional as well as functional requirements. The product roadmap is crucial for keeping your eyes on the prize, especially in large, complex products. You don’t have to know each specific route, but the overall way must be clear. It’s driven by the product vision and marked by industry events, dates, or key features that must be achieved along the route.

Customers (or “product owners,” in Scrum terminology) drive Agile planning, constantly reprioritizing requirements and evaluating risks and dependencies. Close customer collaboration is essential. One of the original Agile methods, DSDM, has customer involvement as the first principle.

Your Agile backlog, or catalog, of product needs changes constantly-whenever you do planning (e.g., for a release or iteration) or, if you’re using a kanban/flow model, every time you’re ready to pull in another requirement. Plans are based on deciding what to build, and when.

An Agile delivery team works ahead, preparing requirements for development and testing. This preparation is vital to deliver the value as soon as possible, with smooth flow and no thrashing or interruptions in delivery and testing.


An Agile team’s work is based on building concise, fine-grained requirements (typically captured as user stories). Developers need small, tamped-down requirements to work from. Small requirements that have clear conditions of satisfaction (doneness) minimize risk.

The team may also sketch organic data models, state diagrams, and interface mockups. These are like micro-specifications: “ready” requirements for pulling into delivery. The team knows enough to estimate, develop, test, and demonstrate the requirements.

Doneness is a key aspect of requirements. I wrote about “done” requirements in my first book (2002): the team and customer need to know when they understand the requirements enough to build and test. This concept is used often in Agile development and refers not only to requirements but also to the build, test, and release process.


Requirements are built and released based on the team’s clear understanding of requirements dependencies, which also drive architecture trade-off decisions. Requirements are dependent on each other when each relies on (and thus constrains) the other.

Smart Agile teams analyze development and delivery dependencies to optimize value. Traditional requirements models are useful for dependency analysis and to supplement Agile’s lightweight requirements (such as user stories).

It’s All Good

“Agile requirements” isn’t an oxymoron, although it may be a bit of a paradox-in the same way that the concise enables the complex, the small gives rise to the large, incompleteness facilitates the finish, and you must slow down to speed up. Indeed, Agile requirements are central to Agile planning, development, and delivery.

Copyright Ellen Gottesdiener, 2011

Don’t forget to leave your comments below.

Ellen Gottesdiener with EBG Consulting, Inc. is the Principal Consultant and Founder. She helps business and technical teams collaborate to define and deliver products customers value and need. Ellen is an internationally recognized facilitator, trainer, speaker, and expert on requirements development and management, Agile business analysis, product chartering and roadmapping, retrospectives, and collaborative workshops.

Author of two acclaimed books Requirements by Collaboration and The Software Requirements Memory Jogger, Ellen works with global clients and speaks at industry conferences. She is co-authoring a book with Mary Gorman on agile practices for discovering and exploring product needs. View her articles, tweets, blog, and free eNewsletter on EBG’s web site.

Amplifying Collaboration with Guerilla Facilitation

Do you ever feel frustrated that you can’t intervene during group gatherings gone astray? How can you take action when you’re not the one in charge? Do you wondering how you can “lead from behind” to improve the quality of your community collaboration?

Here are some suggestions for making meetings or work sessions work better for everyone.

The Writing on the Wall

We humans first communicated with each other on cave walls. Making your content visible on walls for everyone to see and react to is probably one of the most powerful ways for groups to communicate. You can take advantage of this strong visual orientation by becoming the group’s recorder. In this way, you can assist the facilitator (and perhaps act as co-facilitator).

To take this action, be prepared with flipchart paper, wall-friendly tape, and markers. At the meeting, record key summary points, decisions, actions, and a parking lot, perhaps on separate posters. (The parking lot is a place to store topics you want to cover later.) Be sure you honor people’s words. Don’t paraphrase without getting permission.

At the same time, you can facilitate the discussion by checking in with the group on anything you write. Here some examples of questions you should ask:

  • “So can I summarize that by writing . . .?”
  • “Can I capture that idea by writing . . .?”
  • “Looking at what I just wrote, does that summarize your point?”
  • “Can you headline that so I can capture it on our poster?”

Depending on your relationship with the facilitator or meeting leader, you might ask permission to do this ahead of time. Or you might turn to the meeting leader (if there is one) and ask whether it’s OK for you to record key points from the session.

Do You See What I See?

One of my most profound learning experiences as a facilitator was the time I acted as an observer rather than a participant or a facilitator. (My mentor suggested I do this because I felt lost not being in the role of the facilitator!)

Being an observer forced me to focus strictly on studying the group dynamics, watching the flow of interactions, making a point of noticing nonverbal behavior, and sensing the ebb and flow of energy in the group. When I started to see a pattern, I then shared my observation with the group without suggestion or judgment.

For example, I would say, “I noticed when we were discussing , most people made comments and were looking at each other. But when the topic of came up, some people leaned back, others kept glancing toward the clock or door, and there seemed to be less energy in the room.”

You can transform your observations into meta-observations by inviting feedback on the observation itself. You do that by stating the observation, following it with your own inference or assumption, and then checking it out with the group. For example, you could say, “When we were discussing , I noticed more people spoke up. I’m guessing that the topic of is more important to everyone than . Do I have that right?”

By noticing and pointing out specific, observable behavior, you enable the group to “process its process” (what we might call the meta-process). Most of us participate in gatherings without thinking about the group process itself, let alone how to increase its effectiveness.

Acting as an observer and sharing your observations with the group help the group to process its process and thereby improve it. These practices also increase your own skills in being a facilitator, because effective facilitators are expert observers.

Purpose, Products, and Process

If you are not the facilitator and the meeting has no agenda or stated purpose, ask for them ahead of time. If you do not get them but choose to attend anyway, interject early on by asking, “What is the expected outcome of our time together?” Help guide the answers by asking about the meeting’s purpose, products, and process.

When people begin to respond with these questions, stand up and write them on poster paper with the label “Outcomes.” If posters aren’t feasible, ask to take notes (on your laptop, if you have one with you, or by hand if not), which you’ll send out after the session.

Having the outcomes posted on the wall will keep everyone focused on what the group needs to produce. When you hear off-topic discussions, you can point to the outcomes poster and ask, “How does this discussion get us to our outcomes?”

CARES from Your Chair

You don’t have to be the facilitator to use the techniques of an effective facilitator. From where you sit, you can take specific actions to help the participants improve their process. Here are some tips, gathered under the acronym CARES (clarify, ask, reflect, explore, summarize).

Clarify: Check for understanding by asking a question such as, “So are you saying you are concerned about whether this requirements should be in scope or not?” or, “Earlier you said , and now I hear you saying, and these seem in conflict. Can you clarify that?” or simply, “Do I hear you saying . . .?”

Ask: Well-timed questions can have a powerful effect on a group process and promote shared understanding. For example, ask process questions to help redirect a group gone astray: “Is this topic relevant to achieving our planned outcome?” “Is that a topic we might put on our parking lot?” Focus questions help elicit specific information. When you ask, “What are some of the key pieces of information that are used to make that decision?” you will obtain a directed list that’s relevant to the topic at hand.

Context-free questions (Gause and Weinberg, 1989). Such as “What problem does this solve?” or “What problems could this software | process |requirement > create?” expands the community’s thinking about the nature of the project, situation, problem, solution or requirements. Reflective meta questions (Gause and Weinberg, 1989 ) promotes introspective in the group. Asking “Do the questions we’re asking about product requirements relevant?” “Are we the right people to answer these questions?” “Are there other questions we should be asking?” helps the group think about their collaborative thinking.

Reflect: Effective groups continually check on their own process. Don’t wait until the end of the meeting or session to make effective use of self-reflection. Ask, “How do you all think we are doing in making progress here today?” “Can I do a process check and ask everyone if they think we’re heading in the right direction with our time today?” “I’m curious whether this session is productive for us right now. What do you think?”

Explore: Don’t assume that everyone understands or agrees about the topic at hand. Some participants aren’t vocal, or their nonverbal behavior is ambiguous. Do their folded arms indicate contemplation or disagreement? Does foot tapping indicate impatience, anxiety or too much caffeine? Don’t guess where they stand, and don’t assume you know what they know. Ask!

Open-ended, exploratory questions probe for more information. Posing questions like, “I am curious to hear what concerns or suggestions some of the folks who haven’t chimed in yet might have. Would you share that with us?” or, “Can you explain further the impact of on our organization?” can unleash powerful information sharing.

Summarize: Accelerate the group’s process by wrapping up a topic with summary statements or questions. It also helps groups move toward closure. Start by making a statement such as, “To wrap up this discussion: everyone agrees the scope should not include , and we need to revise our scope model” or, “I hear us agreeing to ask the customer to help us develop user acceptance tests in the next iteration.”

Don’t Go

If you’ve tried these actions to no effect or have asked permission of the person in charge to do so but have been turned down, then your last resort is to not participate. In the end, we are responsible for making optimal use of our time to serve our end customers. If you can be more productive doing other work than attending an ineffective group sessions-and you have honestly explained your reasoning for not attending-you are acting in a professional manner. Indeed, your example might inspire your colleagues to follow suit.

In Sum

Collaborating teams are comprised of individuals who take personal responsibility for not just their own behavior, but also for promoting healthy collaboration of the group itself. That includes ensuring valuable use of the group’s time together. We have all heard about the staggering cost of ineffective meetings. We don’t need to be victims or contribute to the waste. If the process is not working and you’re not the designated facilitator or leader, you can still take corrective action. These suggestions are small but powerful ways to affect your project community.

Don’t forget to leave your comments below.

(This article first appeared in Sticky Minds, 2010)

Ellen Gottesdiener is the Principal Consultant and Founder of EBG Consulting, Inc. She helps business and technical teams collaborate to define and deliver the product customers value and need. Author of two acclaimed books Requirements by Collaboration and The Software Requirements Memory Jogger, Ellen works with global clients and speaks at industry conferences. As an agile coach, trainer, and contributor to the agile IIBA BABOKTM agile extension, Ellen is passionate about sharing the value of agile practices for analysis, and the discipline of analysis for agile value delivery. Learn more from her articles, tweets and blog, free eNewsletter and find variety of useful practitioner resources on EBG’s web site.


Gause, Donald C. Gause and Gerald M. Weinberg, Exploring Requirements: Quality Before Design, Dorset House, 1989

Gottesdiener, Ellen, Requirements by Collaboration: Workshops for Defining Needs. Addison-Wesley, 2003.

Tabaka, Jean, Collaboration Explained: Facilitation Skills for Software Project Leaders. Addison-Wesley, 2006.

Copyright © EBG Consulting, Inc., 2010

Agile Business Analysis in Flow: The Work of the Agile Analyst (Part 2)

In Part 1 of “Business Analysis in Flow – The Work of the Agile Analyst ,” I talked about the new skills and attitudes business analysts need to bring to agile development. When your organization adopts this value-centered approach, you need to have, as I wrote, “a tolerance for ambiguity along with a concurrent drive for specificity and closure.”

Now it’s time to talk specifics. What exactly do BAs do in agile development? How will your activities differ from those of traditional development? Let’s take a look at agile business analysis from the perspective of the activities that make up requirements development and management, comparing traditional with agile analysis.

Setting the stage: Requirements planning activities

To set the stage for requirements, the team strives to create a shared understanding of the product by all the stakeholders.

Traditional Analysis Agile Analysis Adaptation
Attend project chartering sessions to define a vision, glossary, requirements risks, and product stakeholders.
  • Design, facilitate, or participate in product vision and roadmapping workshops.
  • Help your customer understand which roles and themes to best deliver in each product release.
  • Help your customer and team identify logical groupings of value-based requirements, and use these groupings to create a product roadmap showing incrementally delivered requirements over time. These requirements often take the form of minimally marketable features, stories, or epics (i.e., large stories that cross releases), use cases (high level only), events, or a combination.
Review and modify a list of tasks, time, and delivery dates in a work breakdown structure plan developed by the project manager.
  • Design and facilitate (or participate in) release and iteration planning workshops.
  • Regularly prune the product backlog by collaborating with team members to generate a relative size estimate for backlog items.
  • Conduct analysis “spikes” (short, timeboxed research stories) to elaborate on backlog items that need more analysis, researching requirements and their priorities.

Generate a SWAG (“S#*&-Wild-Ass-Guess”) estimate of time, effort, or cost for each requirement in the specification or user requirements document.

  • During iteration planning, together with the rest of the team, write down the needed tasks to deliver each user story, and estimate how many hours they will take.
  • Share actual time usage information with your team so that the team can track progress via visual graphs (“information radars”) such as burndown, burn up, or cumulative flow diagrams.

Requirements elicitation activities

During requirements elicitation, the team identifies the sources of requirements and then discovers, derives, evokes, and elicits requirements from those sources.

Traditional Analysis Agile Analysis Adaptation
Plan how to elicit requirements using a variety of techniques.
  • Use face-to-face, collaborative elicitation techniques (workshops, prototypes) as much as possible while avoiding techniques (interviews, surveys, documentation study) that require longer lapse times or interpretation.
Plan, design, and facilitate requirements workshops over weeks (or months).
  • Plan and facilitate short, informal requirements modeling sessions throughout each iteration.
  • Plan and facilitate product vision and roadmapping workshops and release planning workshops.
  • Teach your customer about supplemental analysis models so that they can question, participate, critique, review, and approve them (this should be done in traditional projects as well).
  • Sketch out prototypes and identify user acceptance test data in real time, while a story is being designed, coded, and prepared for testing.

Requirements analysis activities

During analysis, the team seeks to understand and define requirements so that stakeholders can prioritize their needs and decide which requirements to build.

Traditional Analysis Agile Analysis Adaptation
Define the scope up front by using a set of requirements models as the basis for detailed modeling.
  • Help your customer define the vision and the scope up front-at a high level only.
  • Help your customer and team create lightweight models during product roadmapping and release planning. These models help customers carve out a value-based release schedule that balances business priority with architectural dependencies.
  • Collaborate with architects and developers on design to ensure that requirements include the technical aspects of the product.
Develop analysis models for the entire set of requirements that are in scope.
  • Help your customer and team develop stories (user stories as well as stories that incorporate or separately define quality attributes).
  • Help your customer and team develop and extend analysis models that support understanding backlog items selected for delivery in an iteration-if and when needed.
Ask the customer to prioritize requirements using a ranking scheme. If the customer is not available, do the ranking yourself.
  • Help your customer assign a business value and a ranking to each backlog item.
  • Help your customer understand requirements dependencies that might warrant adjustments to backlog rankings.
  • Question rankings based on goals or themes for upcoming release or iterations.
  • Assist your customer and team to right-size high-priority backlog items that are too big to deliver in combination with other high-priority backlog items in the next iteration.

Requirements specification activities

Specification involves refining and organizing requirements into documentation (typically a software requirements specification). This includes the entire set of functional and nonfunctional requirements to be transformed into design, code, and tests.

Traditional Analysis Agile Analysis Adaptation
Write a requirements specification.
  • Help your customer and team write stories (or if you’re acting as proxy customer, you write them).
  • Create doneness criteria for stories so that each becomes a well-defined, small piece of valuable software for delivery in the next (or current) iteration.
  • Create user acceptance tests or sample input and output data for each story.
  • Determine the form and format of documentation that is necessary and sufficient for requirements-related work-in-progress, handover, or product documentation.

Requirements validation activities

During validation, the team assesses whether the product satisfies user needs and conforms to the requirements.

Traditional Analysis Agile Analysis Adaptation
Set up and run meetings to review and sign off on requirements documents, and help customers run acceptance tests after the entire product’s code has been created.
  • Meet with the customer and some team members to prune the backlog (once or twice each week).
  • Participate in iteration demonstrations and listen to stakeholder feedback on the delivered requirements to learn the customer’s real needs and determine how to adapt the evolving product.
  • Plan and facilitate, or participate in, iteration retrospectives, and learn from the customer how you can help deliver value faster.
Communicate with developers or testers (or respond to their e-mails and calls) to explain information in the requirements document; attend or run formal requirements review meetings.
  • Conduct just-in-time analysis modeling with customers and your team to validate the business value of each story and to ensure it will be delivered to the customer’s satisfaction.
  • Participate in daily stand-ups.
  • Sit with developers and testers as they are building code and tests to explain the story and its doneness criteria.
Help testers create user acceptance tests, or run those tests, after the entire product has been designed, coded, and unit/system/integration tested.
  • Define input data and expected results or specific user acceptance tests as part of defining doneness for each user story, iteration by iteration.

Requirements management activities

Requirements management involves monitoring the status of requirements and controlling changes to the requirements baseline (“a point-in-time view of the requirements that have been reviewed and agreed upon to serve as the basis for further development,” Gottesdiener 2005).

Traditional Analysis Agile Analysis Adaptation
Establish the requirements baseline, document change control processes, and generate requirements trace matrices.
  • Help the customer and team establish a product backlog and define the smallest necessary requirements attributes for each backlog item.
  • Help the customer and team define “just enough” requirements tracing needed to satisfy external regulatory body expectations.
  • Help the team determine simple, meaningful requirements mapping and organizing (features to stories, events to stories, etc.).
  • Define simple, unobtrusive ways to trace stories, with the aim of capturing metrics that will be useful for reuse and promoting development efficiencies.
Attend or schedule change control meetings.
  • Help the customer and team prune the product backlog continually (reprioritize items, break down stories, assign rankings, estimate size, and explore requirements dependencies that will impact architecture and therefore release planning).
  • Help the customer maintain the product backlog items (on story cards on a wall, in a spreadsheet, or using an industrial strength agile requirements management tool)-or do this on behalf of the customer.

Learning: The heart of agile success

A mantra for agile teams is “inspect and adapt.” This means regularly checking on the delivered product and the processes used. Continuous improvement (called “kaizen” in lean approaches) is essential to agile success. How do you inspect and adapt your business analysis work to learn and develop?

Traditional Analysis Agile Analysis Adaptation
  • Participate in milestone or project “lessons learned” sessions to find out what went wrong, what went right, and who is responsible for the problems. The project manager fills out the lessons learned template and writes the closeout document.
  • Sit with your manager once or twice a year for a performance review, and get feedback on your performance, months or weeks later. Sometimes that feedback includes second-hand comments from your customer and team.
  • Use acceptance tests, examples, sketches, simple drawings, and face-to-face communication to get feedback on your understanding of requirements.
  • Participate in daily stand-up status meetings to hear the impact you are having on other people’s ability to deliver.
  • On any given day, as an item you committed to deliver is deemed done, show it to the customer to get feedback on it and confirm that the conditions of satisfaction have been met.
  • Design and facilitate, or participate in, iteration and release retrospectives (every two or three weeks, depending on your iteration timebox) to learn what works, learn what to adapt, and collaboratively agree on one or two things to do differently in the next iteration or release. The goal is to learn, adapt, get better, and experience joy in your work.

The new world of agile analysis

So there you have it – a bird’s-eye view of how business analysts operate and add value in agile projects. As you can see, this approach calls on you to stretch your analysis muscles.

As an agile analyst, you are deeply committed to delivering business value and building the right product as soon as possible. As a member of an agile team, you are less concerned with roles and job boundaries, and more concerned with delivering as a team.

You experience the rhythm of successive elaboration and product delivery. You thrive on feedback and small, continual improvements. What’s more, you have an intense need to self-reflect, communicate transparently, improve your skills and abilities, and serve your team and customer. You thrive on the energy and joy of being in rhythm with an agile team.

The author would like to thank Phil Abernathy, Susan Block, Mary Gorman, Kamal Singh, Norman Stang, and Stephanie Weiss for their helpful review and feedback on a draft of this article.

Copyright © EBG Consulting, Inc., 2009

(This article first appeared in Modern Analyst, May 2009)

Don’t forget to leave your comments below.

Ellen Gottesdiener is the Principal Consultant and Founder of EBG Consulting, Inc. She helps business and technical teams collaborate to define and deliver the product customers value and need. Author of two acclaimed books Requirements by Collaboration and The Software Requirements Memory Jogger, Ellen works with global clients and speaks at industry conferences. As an agile coach, trainer, and contributor to the agile IIBA BABOKTM agile extension, Ellen is passionate about sharing the value of agile practices for analysis, and the discipline of analysis for agile value delivery. Learn more from her articles, tweets and blog, free eNewsletter and find variety of useful practitioner resources on EBG’s web site.


Gottesdiener, Ellen. The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements. GOAL/QPC, 2005.

Agile Business Analysis in Flow: The Work of the Agile Analyst (Part 1)

“Life is about not knowing, having to change, taking the moment and making the best of it without knowing what’s going to happen next. Delicious ambiguity.”
-Gilda Radner, actress and comedienne (1946-1989)

Agile is here, and it’s coming soon to an organization near you-if it’s not already there. As a business analyst, are you ready to make the transition to this value-centered development approach? How will your role change? What will you do differently? What will you actually do as part of an agile team? What agile analysis practices might you adapt if you’re working on a traditional (waterfall-style) project?

In short, how can you make yourself more valuable to your agile team and organization using your business analysis skills and abilities?

It’s about the work, not the role

Keep in mind my bias: it’s not about the job role or title you have, it’s about the work. So when I use the term “agile business analyst,” I mean anyone who is doing the work of requirements (business) analysis on an agile team.

Some agile teams may not have a team member who is the designated business analyst, or they may have a business analyst whose only role is business analysis and requirements-related work. A variety of people who have the skills may do the work of analysis, and it may be shared among team members. That is common in small projects or when the team members have rich business domain expertise along with close, trusting relationships with their business customers.

So if you are (or will be) doing the work of agile analysis, keep reading to find out how your life will change.

With agile, value comes from the customer

On agile projects, the customer has the responsibility-and the burden-to decide which items the delivery team will build and when, and to define each item’s “doneness criteria” (when it is acceptable for release). In essence, the customer is responsible for product profitability. By understanding the product’s market or business need and advocating for the voice of the (end) customer, the customer embodies the core mantra of agile teams: deliver value.

For the project to succeed, the customer must conduct a mix of strategic and tactical activities. Strategic activities include analyzing the market and business case, defining the product vision and roadmap, developing requirements, adjusting the product backlog, and determining delivery plans. The customer also conducts tactical activities such as specifying the items to be delivered in each iteration, determining when each item is complete, analyzing dependencies between items, and helping the team analyze requirements stories.

To fulfill both strategic and tactical activities on an agile project, the business customer needs product development experience, along with deep domain and product knowledge. Understanding the underlying technology also helps when making “techno business” decisions throughout product development.

With all these responsibilities, in some organizations, the business customer needs help with day-to-day tactical decision making. That’s where you, as an agile business analyst, come in. On some agile teams, a BA who has deep domain knowledge (and perhaps has served in a business role) serves as the tactical customer (or, in a Scrum project, the “product owner”) or splits those responsibilities with the business customer. By serving as the tactical, iteration-level customer, you free the senior business customer to be the team’s strategic customer. You leverage your analysis skills to help your team deliver value, one iteration at a time. You ensure each delivery aligns to the overall strategy and goals.

What will change when you’re on an agile team?

Processes, products, and relationships change on an agile team. How you plan the work, deliver the product, represent requirements, share knowledge, interact with your team and customer, manage changing requirements, and document requirements will be quite different from traditional, waterfall-style projects.

In short, you will be part of a team of highly collaborative colleagues with a furious focus on delivering value, negotiating value delivery in short cycles, and helping your business partners understand what they really need-not only up front but also as the product unfolds in small, usable chunks.

Business analysts must relinquish control of the requirements, the customer relationship, and the usual requirements documentation. Why? It’s because on your agile team, you deliver working, valuable software every few weeks. And you (and your team and customer) don’t know exactly what the end product will be-not until you start to build it, deliver it, and get feedback on it. That’s when you learn what the need really is.

Business analysts must relinquish control of the requirements, the customer relationship, and the usual requirements documentation. Why? It’s because on your agile team, you deliver working, valuable software every few weeks. And you (and your team and customer) don’t know exactly what the end product will be-not until you start to build it, deliver it, and get feedback on it. That’s when you learn what the need really is.

That’s why I like to quote Gilda Radner’s phrase “delicious ambiguity.” An agile project is all about suspending control for as long as possible.

Even team roles can be ambiguous. Specifics may vary, but an agile team collaborates to deliver to a committed set of requirements. Each team member is willing, even eager, to do whatever it takes to make that happen, no matter what the official job responsibilities dictate.

It’s likely that you will not be the only one to elicit, analyze, and specify requirements. The team is focused on delivering “shippable” software in short cycles (iterations), so your tasks may cross over to other activities that call on your skills, capacity, and interest. For example, you are likely to identify-if not also create and execute-user acceptance tests: hands-on validation. Your soft skills and understanding of requirements dependencies make you a good candidate to facilitate planning workshops to define the product roadmap and release plans.

As an agile business analyst, you’re no longer shackled to large, complex requirements documentation and templates. Instead, you will influence your business partners and teams to rethink what kind of (and how much) documentation is needed. You may deliver documentation in small chunks, along with the small, useful chunks of requirements your team delivers in each iteration (often in the form of user stories). You might pitch in to develop lightweight product, user, or support documentation.

Your work is both tactical and strategic: you need to grasp the big view (the product vision, roadmap, and release plans) while maintaining a firm footing in the now (the current iteration). Thus you need the discipline and flexibility to operate in multiple modes (the “now” of the current iteration and the “later” of upcoming iterations).

Your work will be transparent. You will get better at estimating and working with your cross-functional teammates to reliably predict how much software your team can deliver in each iteration. The visibility of iteration planning, end-of-iteration demonstrations, and retrospectives permit no hiding. You will find greater mastery by being openly accountable to your customer, the team, and yourself.

Until next time

In the second part of this article, we’ll take a close look at specific business analyst activities that differ in agile projects. We’ll frame these tasks in the context of traditional requirements engineering, which involves setting the stage; developing (eliciting, analyzing, specifying and validating) requirements; and managing requirements (Gottesdiener, 2005).

There’s never been a more exciting time to be a business analyst. Are you open to the challenge? Can you adapt your skills to your agile team’s steady beat of short, value-driven cycles? Can you influence your traditional team to alter your analysis practices? Stay tuned.


The author would like to thank Phil Abernathy, Susan Block, Mary Gorman, Kamal Singh, Norman Stang, and Stephanie Weiss for their helpful review and feedback on a draft of this article.

(This article first appeared in Modern Analyst, May 2009)

Don’t forget to leave your comments below.

Ellen Gottesdiener is the Principal Consultant and Founder of EBG Consulting, Inc.  She helps business and technical teams collaborate to define and deliver the product customers value and need. Author of two acclaimed books Requirements by Collaboration and The Software Requirements Memory Jogger, Ellen works with global clients and speaks at industry conferences. As an agile coach, trainer, and contributor to the agile IIBA BABOKTM agile extension, Ellen is passionate about sharing the value of agile practices for analysis, and the discipline of analysis for agile value delivery. Learn more from her articles, tweets and blog, free eNewsletter and find variety of useful practitioner resources on EBG’s web site.

The Top Nine Requirements Misconceptions: Why Arent YOU Doing Requirements Right?

“We don’t need to explore requirements—we know what we need!” “Hey, we’re using agile methods—we don’t need to define requirements!” “Oh, we don’t have time for requirements!” And so it goes. You’ve probably heard—and perhaps yourself offered—any number of excuses or rationales for not doing requirements right. No matter who makes these excuses—technical staff, the business sponsor, the project manager, or even business analysts—failing to carefully define your project’s requirements will put your project in peril. In my twenty years of working with projects, I’ve heard them all. Here are my top nine requirements misconceptions—and how you can refute them.


“We know what we need”

In practice, project team members mostly don’t know what users or customers need. Requirements development takes exploration and learning. It’s unrealistic to expect your team to understand requirements up front.

For one thing, users, product managers, customers, and other stakeholders don’t really know all their needs at the beginning. Requirements naturally thrash and evolve. Indeed, it’s wise to be suspicious of claims to the contrary. Remember, almost half of the requirements you specify never get implemented (Standish Group International, 2003b).

In many projects, the perception that requirements are known is mistaken. Most errors in delivered software (30% to 50%, depending on the study) originate from flawed requirements (Schwaber, 2006; Nelson et al., 1999; Leffingwell and Widrig, 1999; Lauesen and Vinter, 2001).

The top three risks that threaten successful e-projects all relate to requirements— constantly changing requirements, poor requirements specification, and customer involvement issues such as delayed approval, requirements thrashing, and poor communication (Rodrigues, 2001).

Don’t rely solely on product and business managers for defining user needs. Unless they are former users themselves, they will not understand direct user needs without inquiry and exploration. And rarely do product and business managers have the subject matter expertise you need to represent the entire set of requirements.

Ask yourself: have you solicited the voices of all your stakeholders? Do you know who all your stakeholders are? Have you prioritized conflicting needs? Have you explored both technical constraints and possibilities? You may think you know what the needs are, but your list may be shortened by technical realities or lengthened by technology possibilities.

What you think you know can hurt your project more than what you don’t know.

“We’ve got this covered. We’re [pick one: outsourcing/
using agile development methods/ buying a software package]”

Outsourcing, agile development methods, COTS solutions—these are often great ideas, but they don’t eliminate the need to develop excellent requirements. You still need to articulate requirements, adapting your requirements development practices to these scenarios.

The critical need for proper requirements development increases when you outsource your project. You need to communicate requirements with even more rigor when the development staff is not physically co-located with customers and project managers. In addition, you will need top-notch business analysts (Schwaber, 2006).

If you’re adopting agile practices, it doesn’t mean you don’t need requirements. In agile projects, iterations are driven by requirements. They don’t go away—they’re successively elaborated.

And if your product is large and complex, agile projects need to start with a requirements-driven product and release roadmap. From there, the team develops chunks of requirements—based on those roadmaps. Success with agile development means balancing suitable-quality requirements with speedy definition of needs.

Many organizations hope to accelerate delivery by seeking and installing software package solutions (commercial off-the-shelf software, or COTS). In that case, you still need to understand your requirements and the impact your project will have on your business process. Requirements should drive your choice as well as your implementation strategy.

“My staff already knows what good practices are”

Too many projects rely on written requirements, often viewed as the most important good practice. But written requirements are rife with ambiguity (unclear meanings). To top it off, project and product needs are rarely known up front.

In fact, writing textual requirements (“the system shall…”) is not the best way to understand your users’ needs. Textual requirements have their place when you need formal specifications, but most successful projects also adopt other techniques to explore business and user requirements.

Effective requirements development makes use of requirements models that are verified and validated continually and iteratively. Using good practices—such as requirements modeling, facilitated workshops, prototypes, scenario verification, and more—takes practice, coaching, and reinforcement.

Following sound requirements processes, actively involving users, documenting requirements appropriately, validating and verifying requirements, and managing requirements changes—all these skills and techniques are essential to successfully reduce the many risks associated with requirements errors (Leishman and Cook, 2002).

“We can’t afford to get training or consulting”

Roughly one-third of your software project budget is consumed fixing requirements errors. That means you’re spending about $150,000 of your $500,000 project fixing defects or errors that originate from your requirements (Schwaber, 2006; Nelson et Al., 1999; Leffingwell and Widrig, 1999; Weinberg, 1997).

The earlier you discover these errors—missing, wrong, conflicting, and ambiguous requirements—the cheaper it is to fix them. Finding and fixing a requirements error during the requirements phase might cost you $25 to $100. If you don’t find it until the construction or testing phase, fixing that same error is going to cost you $500 to $1000 (20 to 40 times more). Left undetected, that requirements error will cost you as much as 300 to 1,000 times more. That $25 cost becomes $10,000! (Reifer, 2007)

For every dollar you invest in your staff learning good requirements practices that incorporate customer collaboration, you can get a 10:1 return on investment (Jones, 1996a).

You cannot afford not to correct your requirements deficiencies.

Pay now—or pay more, later!

“It will take too much time to do things differently, to take time out for training, or get project help from the outside”

Yes, there will be a learning curve. This is a normal part of change and learning. But there are things you can do to accelerate the process. Schedule formal training to coincide as closely as possible with the project work. Provide real-time coaching to the team. Set up sponsorship contracts so that new practices and behaviors are reinforced in the organization—both top-down and bottom-up. Find out from your staff what they need from you to be successful with requirements, and provide it.

And remember, some requirements work is better than none. On complex projects, one study showed that investing even 10% in the effort before freezing requirements reduces cost overruns significantly (NASA Comptroller Office, reported in Hooks and Farry, 2001).

Many organizations are turning to external service providers, outsourcing their development efforts. And they are learning that highly skilled business analysts who can develop and manage requirements are essential to successful outsourcing (Henschen et al., 2007; Light, 2005).

“Users don’t know what they want”

Users are not supposed to know what they want. Understanding user needs is both an art and a science—a combination of discovery, interrogation, exploration, and decision making.

Involving users in requirements development is widely recognized as one of the—if not THE—most important factor for project success. Yet business people, as well as IT people, continue to complain about their inability to work effectively together to define the right requirements.

Healthy collaboration with users is crucial—and it doesn’t just happen. Both sides of the relationship—business and IT—are accountable to co-develop the right requirements in the most efficient and effective manner possible.

That’s why great analysts employ an appropriate combination of requirements elicitation techniques. It’s one of their most valued skills. These elicitation skills, married with artful choices in requirements models, go a long way toward active and productive user involvement.

Sponsors who pay for the development (product managers, marketing managers, or internal business managers) also need to be engaged. This doesn’t take unlimited time and money. Not all requirements are created equal. User priorities need to be evaluated continually if the team is to make smart product development choices.

“Customers are too busy to participate in requirements work with us”

IT needs to employ techniques that make good use of business people’s time and actively engage them in requirements work. At the same time, business people need to fully participate in defining their requirements. If you do it right, good practices for effective user involvement sell themselves.

Here are some ways to do it right. Represent user needs in ways that “sing” to users and customers. Use a variety of elicitation techniques. Verify and validate requirements as you proceed. And, importantly, conduct continual requirements retrospectives to get feedback that will allow you to adapt your requirements practices.

“Our users are distributed. We can’t get everyone’s requirements”

User requirements are the focal point of your product. When users are scattered, you still need to identify the various types of users, understand their needs, and determine how you might need to alter requirements based on location.

When your users are geographically distributed or there are vast numbers of them, you may have to rely on surrogate users or subject matter experts who can research user needs. Find a small sample of representative users from various locations who are important to product success. Then adapt your elicitation practices to make efficient use of these users in requirements development and verification.

For some products, it’s best to combine surveys and other research methods with deeper representative user involvement.

Regardless of the approach you take, ignoring user needs is a recipe for disaster.

“We got the book We’ll just follow that”

Reading a book (e.g. The Software Requirements Memory Jogger) helps. It gives you awareness and knowledge. Reading does not, however, enable you to apply skills without practice and reinforcement.

Many business and requirements analysts are not trained and skilled in the toolkit of requirements development and management practices they need to be successful (Schwaber, 2006).

Analysts with extensive experience are more successful than novices in analyzing and uncovering user needs. Expert analysts demonstrate the ability to select among elicitation techniques based on the situation and integrate multiple models to represent requirements (Hickey and Davis, 2003).

Gaining expertise in requirements saves time and effort, reducing your total cost of application ownership (Light, 2005).

Training and coaching accelerate the learning curve and will earn you savings in time and money.

Copyright: Ellen Gottesdiener 04/23/07

Ellen Gottesdiener, Principal Consultant, EBG Consulting, helps you get the right requirements so your projects start smart and deliver the right product at the right time. Her book Requirements by Collaboration: Workshops for Defining Needs describes how to use multiple models to elicit requirements in collaborative workshops. Ellen’s most recent book, The Software Requirements Memory Jogger describes essentials for requirements development and management. In addition to providing training and consulting services, Ellen speaks at and advises for industry conferences, writes articles, and serves on the Expert Review Board of the International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge™ (BABOK™). You can subscribe to EBG Consulting’s free monthly eNewsletter Success with Requirements ( for practical guidance and requirements-related news. When you sign up, you’ll receive a free .pdf article by our Senior Associate, Mary Gorman, on an essential requirements modeling technique.

Henschen, Doug, David Stodder, Penny Crosman, Michael Mcclellan, Neal Mcwhorter, and David Patterson. 2007. “Seven Trends for 2007.” Intelligent Enterprise, January. See

Hickey, Ann M., and Alan M. Davis. 2003. “Elicitation Technique Selection: How Do Experts Do It?” Proceedings 11th International IEEE Requirements Engineering Conference. September.

Hooks, Ivy F., and Kristin A. Farry. 2001. Customer-Centered Products: Creating Successful Products through Requirements Management. Amacom.

Jones, Capers. 1996a. Patterns of Software Systems Failure and Success. Thomson Computer Press.

Lauesen, Soren, and Otto Vinter. 2001. “Preventing Requirement Defects: An Experiment and Process Improvement.” Requirements Engineering, June 6:37-60.

Leffingwell, Dean. 2003. “Calculating the Return on Investment from More Effective Requirements Management.” IBM Developer Works, December.

Leishman, Theron R., and David Cook. 2002. “Requirements Risk Can Drown Software Projects.” Crosstalk: The Journal of Defense Software Engineering, April.

Light, Matt. 2005. “Agile Requirements Definition and Management Will Benefit Applications Development.” Gartner RAS Core Research Note G00126310, Gartner, April 18.

Nelson, Mike, James Clark, and Martha Ann Spurlock. 1999. “Curing the Software Requirements and Cost Estimating Blues.” The Defense Acquisition University Program Manager Magazine, November–December.

Reifer, Donald J. 2007. “Profiles of Level 5 CMMI Organizations.” Crosstalk: The Journal of Defense Software Engineering, January.

Rodrigues, Alexandre G. 2001. “Project Goals, Business Performance, and Risk.” Cutter Consortium e-Project Management Advisory Service Executive Update, 2(7).

Schwaber, Carey. 2006. “The Root of the Problem: Poor Requirements.” IT View Research Document, Forrester Research, September.

Standish Group International, Inc. 2003b. Standish Group Study. Reported by Jim Johnson, chairman, XP 2002 Conference.

Weinberg, Gerald M. 1997. Quality Software Management, Volume 4: Anticipating Change. Dorset House.


  • 1
  • 2