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 is a story?
In agile development, a story is a work item that needs to be completed to deliver the product. Stories are contained and tracked in the product backlog (the catalog of all the work) and are the basis for iteration planning and development.

A story usually describes a user requirement-something of value that a user needs to do. However, some agilists use the story metaphor for other technical or team-related work, such as delivering nonfunctional requirements, setting up servers, tuning the database, cleaning up bugs, building automated tests, or finding and setting up a team workspace.

A user story is a concise, sharply defined user requirement that briefly describes something valuable the user needs to accomplish. It is usually written in this format: "As a , I want to so that ."

For example, "As a book buyer, I want to read reviews about the book I am viewing so that I can decide whether I want to purchase it" or, "As a corporate librarian, I want to find quantity discount information so that I can compare the price to another supplier's."

A story is a placeholder in the backlog requiring further elaboration-when and if it will be consumed within an iteration. For example, to use a story for iteration planning and development, its conditions of satisfaction, or "doneness", must also be clearly understood.

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.

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). Meanwhile, please direct your questions to me at [email protected].

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.

Recommended Readings:

Author: 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. Ellen's company provides high value training, facilitation, and consulting services to agile and traditional teams. An agile coach and trainer with a passion about agile requirements, she works with large, complex products and helps teams elicit just enough requirements to achieve iteration and product goals.

Ellen's book Requirements by Collaboration: Workshops for Defining Needs describes how to use multiple models to elicit requirements in collaborative workshops. Her most recent book, The Software Requirements Memory Jogger is the "go-to" industry guide for requirements good practices. In addition to providing training and consulting services and coaching agile teams, 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 KnowledgeTM (BABOKTM).

You can subscribe to EBG Consulting's offers a free monthly eNewsletter "Success with Requirements" offering practical guidance and requirements-related news. When you sign up, you'll receive a free article on essentials for scoping your requirements. You can follow Ellen on Twitter or contact her via email.

Copyright © EBG Consulting, Inc., 2009

Like this article:
  8 members liked this article


Adriana Beal posted on Monday, May 11, 2009 11:34 AM

"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."

I wanted to point out that there are several different worlds of software development, and different dynamics apply to different worlds. Most of my projects produce software for internal use, and typically what you describe above is expected from the business analyst working on the project.

The executives or employees who will use the software are normally too busy to go beyond helping establish the vision and participating on a few periodic checkpoints. They trust the business analyst to advocate for the voice of the stakeholders, create the business case, define the product vision and roadmap, develop requirements, adjust the product backlog, and determine delivery plans--simply because they have no time to devote to these activities in addition to their other responsibilities.
Casey K. posted on Monday, May 11, 2009 4:46 PM
Excellent article--I am very interested in part 2, as I am a BA who has been involved solely in the traditional processes of RE. Thanks for making this so understandable.
JohnIMM posted on Monday, May 11, 2009 5:12 PM
Agile is not very different from the worlds of prototyping and incremental development that have been around for many years.

All of these approaches suffer from the "Skills Paradox", namely, those who are most likely to want to use them are the least skilled to do so.

All of these approaches can only be effectively practiced by the most skilled analysts and developers. When practiced by the unskilled or inexperienced they deliver exactly the poor quality software they were designed to avoid.

I totally support delivering quality software that does exactly what it meant to do in a very short time. However, it is totally misleading to suggest that this can only be done by creating a totally unstructured environment.

The software industry is notorious for failing to deliver the right thing first time. Now Agile is trying to legitimise this. It tells the customer "we are not going to deliver the right thing first time but will attempt to get it to you after several tries". In the past this was termed "failure" now it is called "an iteration".

One of the main reasons most software fails to deliver is its flawed underlying structures, especially its data structure. Successful incremental or agile development can only be achieved if there is a strategic business and data model in place on which the software is based, even if the software is delivered in tactical phases.

One of the major obstacles I witness when talking to businesses around the world is the problem of scaleability in their systems.

This is especially the problem where the software was built quickly in order to meet a tactical business need. Now, when the business wants to add another product type, or customer class or taxation structure, the software will not allow it. It was built using an "agile" approach and is now bring the customer to its knees.

Several companies have recently had to abandon plans to expand into other countries due to the fact there their rapidly developed software could not be scaled.

"Delicious ambiguity" may be delightful and exciting for a comedienne, but for a business competing in an ever more challenging economic environment it is no joke!
Alex P posted on Tuesday, May 12, 2009 7:43 AM
Following on from the previous comment (I'll be interested to see your reply), you seem to suggest, reading between the lines, that Agile is growing rapidly and may even become the standard project approach.
In my (admittedly narrow) experience of working for large organisations with large projects I have never seen Agile practiced except for small pilots.
I find this a cause of frustration as I can see the benefits of Agile approaches.
I have only experienced it first hand last year whe I took on the PM role with a startup and had a rapid learning curve to get to grips with Agile. I learnt a lot and became a big fan of restrospectives although it came to an end all too soon.

In my experience in the blogosphere, Agile seems to be a very popular subject in the US. Maybe it's more widely accepted and we're behind the curve in the UK?

I'd value your opinion as someone who has a broader view of trends in business analysis and software development in general.
42something posted on Tuesday, May 19, 2009 12:48 AM
I've done a few agile projects now and it would seem they suffer from the same problem:

1. Prototyping manages expectation as to the delivery of the product. Big mistake. A screen picture is one thing, but if you deliver something different you've lost their confidence. Still something to be said for mud maps IMO. Very easy to mock up utopia. Example, some developer added three stars for priority, looked pretty yes, but added zero business value. I had to convince them it was worthless as it looked good.

2. Behaviour vs Function. The business world is still stuck in the functional world, that waterfall addressed well with all the documentation. Agile scares some businessses as it has a level of chaos,adaptability and trust. Thus communication is the success of it. If the organisation is nortoriously bad with that, agile fails and this isn't an audit trail.

3. Testing. Agile Testing? You need to consider a different set of skills from a tester for agile, get them early. Education in the concept of predictive vs adaptive requirements is paramount. Testers tend to be rigid. I did a lot of work on creating great User Stories only to be scuppered by the externally resourced test team who were not involved up front and had not concept of Agile. Not a pretty picture.

Having said that, once making the leap to agile, I find it difficult now to ever imagine how I spent so many hours ensuring my bullet points lined up and numbering systems were consecutive.

I'd like to add agilist to my title....hope the trend grows. I'm in Australia, so far its ploddnig.
Anonymous User posted on Wednesday, May 20, 2009 3:08 PM
1. Prototyping: I agree that the danger with prototyping was managing the customer expectation - and that was where most prototyping projects failed. I would not recommend prototyping except for use by the most experienced practitioners.

2. Behaviour vs Function. Every core activity in a business is a business function. Many mistake "function" for "department". Not so. the "finance function" is not the "finance department". All behaviour in a business MUST support the business functions or it has no place there. Many analysts make the mistake of modelling current business behavior believing that a) it is probably close to what the business ought to be doing or b) that they can infer from it what the business ought to be doing. I cover this in more detail in "Five Fatal Errors for Business Analysts" at Whatever approach you are taking if you do not model the business functions you will fail to deliver what the business needs.

3. Scared Business: Agile scares business with good reason. IT departments that could not deliver what they promised using structured approaches and are now telling the business that using a method that celebrates chaos and ambiguity will deliver everything they ever dreamed of! Any sensible executive would be highly sceptical.

The argument is not that Agile is good and structure is bad or vice versa. Most good analysts and developers have been using the equivalent of Agile for many years. However, a development team that cannot deliver a system to specification and on time using a structured approach has no chance of delivering it using Agile!

Ellen Gottesdiener posted on Sunday, May 31, 2009 2:18 PM
Thanks to all of you who made comments on my article. Here are responses to your comments:

*A.B.: yes indeed! Agile indeed builds on practices the existed for some included prototyping ala the days of RAD incremental development, pairing, test-driven development, and more. There is a good bit of repackaging and alas, a lot of hyping of agile as the ‘new, new thing’. Agile practices stand of the shoulders of numerous existing techniques. One example of that is Evo, Tom Gilb’s evolutionary project management approach – indeed, Tom is the grandfather of agile! For a more complete history I recommend Craig Larman’s, Craig, Agile and Iterative Development: A Manager's Guide. Addison-Wesley, 2003.

* A.B.: Let’s view the time and money spent building and enhancing software as an investment that requires sound business (including financial) decision making, whether that software will be sold or used internally. Thus, agile practices can apply to both commercial and internal software.

* Execs and SMEs (subject matter experts) are always too busy (aren’t we all!). As mentioned in the article, business analysts with deep domain knowledge can serve as tactical customers (aka customers) to alleviate some of this problem. This does NOT relieve the ‘strategic’ (exec) customer from the ultimate ownership of the backlog and their priorities. This would be an expensive abdication of responsibility. (Jeff Sutherland (one of the ‘fathers’ of Scrum) posits that the customer/product owner is responsible for some 20% of the ROI (return on investment) of the software product).

* Casey K: thanks for you kind words

* I don’t agree with JohnIMM that only the most skilled practitioners can use agile and that those most likely to want to are less skilled. I think that unskilled people, regardless of method, are unlikely to succeed. Bad practices—agile or traditional—lead to poor quality and unhappy customers.

* JohnIMM you state that “it is totally misleading to suggest that this can only be done by creating a totally unstructured environment”. I hope other readers did think I was suggesting working in such an environment! I could be mistaken, but I am inferring from that note that JohnIMM is not fully informed about how agile works in practice, or perhaps has not experiencing working on a agile team using agile practices.

In practice, agile teams are actually very disciplined and ‘structured’: timeboxes delivering working software, frequently rituals (planning workshops, demonstrations/reviews, retrospectives), engineering and quality practices (TDD, continuous integration, definition of ‘done’), transparent progress and management practices (visible tracking via burndowns or cumulative flow diagrams, task or kanban boards, rank-ordered backlog, daily status via the ‘standup’ meeting), etc.

I totally agree, BTW with you JohnIMM in the importance of data (and business rules!). On some teams we use an ‘organic’ data model, one that is continually added to/refactored in each iteration. We have found it to a useful analysis asset for the entire team. In addition, visioning and product roadmapping is essential for large complex products. (see: )

WRT John’s comment on the Radner quote: comedy is an art and science that blends tragedy with humor. In addition to the cleverness of this quote, it is quite serious. Moreover, the serious use of agile practices, especially making tough choices (read Software by Numbers, see is a smart thing to do.

* AlexP: agile is being practiced globally and some very large projects. You can see the # of conferences and gatherings related to agile on the Agile Alliance web site:

Dave West at Forrester research shared in his recent survey (small sample size, but telling nevertheless) respondents response to the question, “Which development method do you follow primarily?” with the answers: Iterative (Unified process) 38%, Waterfall, 32% and Agile: 30%.

Here are some links you might find useful regarding agile adaption and productivity:

Forrester Research: Best Practices: Software Development Processes: A Framework For Improving And Modernizing Your Software Development Life Cycle:,7211,47913,00.html

Forrester Research: Ensure Success For Agile Using Four Simple Steps: A Simple Approach To Agile Adoption And Implementation:,7211,54037,00.html

Scott ambler’s surveys:

Search Software Quality on agile :,289142,sid92_gci1318992,00.html

Agile success factors:

State of agile 2008 report by Version One:

Agile practices:

Many of the practices of agile are known, practical and easy to learn about from a knowledge and understanding point of view. Adopting them—changing behavior—that’s what’s hard.

*42something: thanks for your comments. Sounds like you did a good job focusing on value in the prototyping example you shared. And, I totally agree how important communication and testing is!

* Anonymous User: I do not see prototyping as a project; but as a means to elicit and confirm requirements> If it’s an evolutionary prototype it is also as a means delivering value quickly. I do not think agree that only experts use prototypes. Even a sketch is a prototype, and can be a very powerful way to understanding user experience (e.g., interface and usage), as well as user requirements.

* Anonymous User: You said “if you do not model the business functions you will fail to deliver what the business needs.” I’m not sure I’d agree with that blanket statement. I’m not sure how much modeling you mean. Sometimes a lightweight process map, use case map, user story map, task flow, or sketch of screens is enough. Moreover, some domains are less ‘process’ oriented and more data and rules oriented. In those situations, business modeling might not be the best way to explore needs.

*“Most good analysts and developers have been using the equivalent of Agile for many years. “oh yes, I heartily agree Anonymous User!

* Anonymous User said, “However, a development team that cannot deliver a system to specification and on time using a structured approach has no chance of delivering it using Agile!” I disagree that a predecessor for success with agile is having delivered to a spec. There are many teams who deliver to a spec (most often, late and over-budget) that don’t deliver business value. A spec does not guarantee success. (read Scott Ambler’s article in this same issue,

* In sum: we need to do more practice of good practices, practically applied.
LK posted on Saturday, April 16, 2011 12:53 PM
Thanks for the excellent article.

I feel the 'Business Analyst' in the traditional waterfall approach should be labelled as 'Agile Business Systems Analyst(ABSA)' in Agile paradigm as he/she does both Strategic(Business) and Tactical(Systems) activities. I view it as -a slice of Business and a slice of Systems mixed- to produce workable chunks..
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC