Why Skilled Business Analysts Will Not Go Away in an Agile World


As agile methods become widespread in organizations, it’s not surprising to see the idea of the business analyst as a dispensable role taking root among IT project teams. After all, in agile approaches, tasks typically performed by a business analyst, such as requirements elicitation, analysis and documentation, are replaced by a conversation between customer and developers. As Kent Beck and Martin Fowler wrote in their book Planning Extreme Programming (Boston: Addison-Wesley, 2001, p. 47),

“The shorter the story the better. The story represents a concept and is not a detailed specification. A user story is nothing more than an agreement that the customer and developers will talk together about a feature. Hideous written detail is not necessary if the customer can work with the programmers while they are programming.”

Why Skilled Business Analysts Will Not Go Away in an Agile WorldIn an ideal world, all projects would have an “on-site customer” available to take an active part in the software development process, representing and making clear decisions about the business and end-user needs in a just-in-time manner. In practice though, especially in the case of internal applications, it is more common to have multiple business units sharing a system that supports cross-functional internal processes, with the following consequences for a software development initiative:

1) Instead of a “single customer” with time for daily conversations with developers to clarify requirements, provide feedback on implemented features, and make decisions in a just-in-time manner, the project has to rely on a group of busy senior managers to make collective decisions about the system.  

2) Achieving consensus about priorities and implementation details requires collecting ideas and final decisions from various stakeholders.

3) Refining the requirements and establishing acceptance criteria for stories in the backlog may require research and analysis activities to be performed in advance of each development cycle to support timely decision-making.

Some “agile evangelists” may argue that the described situation precludes agile adoption, because agile requires an on-site customer, or dedicated product owner, or all team members working together in the exact same room, or another unmet requirement. Again, in practice that is not a reasonable expectation. As recognized by many experienced agilists, even though the perfect circumstances may not be present, businesses still want to take advantage of the benefits of a more flexible approach to software development that can support continuous innovation, product, people and process adaptability, and improved time-to-market. And that’s where the business analyst fits in the picture.

Facilitator and problem-solver

Taking advantage of the benefits of an agile approach under less-than-ideal circumstances means adapting agile practices to the reality that businesses faces. In my consulting practice, I have been witnessing a growing demand for senior BAs to join teams working on cross-functional, complex software projects using agile methods. The addition of a business analyst to the agile team is being received with great enthusiasm by both the business and technical groups due to two main desires: to end a vicious cycle of time-wasting meetings (in which conversations about new features wander from one topic to another without reaching any conclusion for lack of a skilled facilitator), and to adopt a more disciplined approach to identifying business and user needs beyond what is explicitly stated, so that the solution built can actually meet those needs without constant rework of existing functionality.

One might argue that such responsibilities should be taken by the product owner (the role that represents the interests of the customers and other key stakeholders in Scrum, a popular "flavor" of agile). Indeed, some product owners do have the combination of skills, desire, and  time to dedicate to the facilitation and problem-solving activities required to achieve consensus about priorities and user story details. If that is the case, in addition to performing their job (manage the product backlog, ensure the right balance between business goals and constraints), the product owner will be fulfilling a BA role as well. The two roles are not to be confused, though: by definition, a product owner has the authority to make decisions about functionalities and project priorities, while an analyst is responsible for helping stakeholders achieve a solid understanding of what needs to be accomplished, but doesn't have the power to cast a deciding vote on any outstanding issues. As well described by Laura Brandenburg in her Business Analyst Manifesto,

On every successful project you’ll find a business analyst. Their title might be director of technology, product owner, product manager, requirements analyst, business process engineer, VP of operations, development lead, team lead, project manager, or CTO. The title is rather irrelevant. The activities of creating alignment around a clear understanding of “done” that creates positive change is what it means to be a business analyst.

A skilled business analyst may become a key member of an agile team by performing tasks like the ones listed below, which the technical and business groups will not necessarily have the time, interest or skills to tackle:

  • Establish effective mechanisms to help stakeholders assess their needs and make timely and well-founded decisions about features, priorities, issues, acceptance criteria.

  • Perform the analytical work necessary to achieve in-depth understanding of the problem and constraints.

  • Manage conflicts using a collaborative approach.

  • Identify epics, user stories, and test conditions in facilitated sessions.

  • Research business and user problems and determine the best solutions in advance of an iteration in order to avoid delays during development caused by lack of clarity about what is required to make a user story successful.

  • Act as a “product owner proxy”, being available on a daily basis to clarify requirements, discuss trade-offs with the development team, and help ensure that the product is intuitive and easy to use.

  • Share progress with the business stakeholders and facilitate the discussion of issues arising in development.

Producer of relevant documentation

Agile places a greater emphasis on working code over comprehensive documentation, but that doesn’t mean that documentation goes away–only that it is reassessed according to the value it provides. Even though documents are not supposed to replace getting the right people in a room to work things out together, the right piece of documentation may be crucial to keep the focus of the team on the rapid delivery of business value.

Documentation (which  doesn’t necessarily have to be formally writte, as it can be composed of visual representations, and even video or audio recordings) may be required  throughout the life of an agile project in different circumstances, including:

  • when an iteration is about to start, and the developers need to be reminded of implementation decisions and hard-to-remember requirements (such as complex business rules that apply to a user story);

  • when the team is preparing to hand off the project to another group that will maintain the product, and readable code plus automated test cases are deemed insufficient to explain system behavior or clarify the reasons behind certain implementation choices that may affect future work;

  • when end users will start to use a new product or feature, and need help understanding how to operate the software;

  • when regulation and compliance issues require a permanent record of implemented system behavior.

Expecting business or technical team members to write readable and effective acceptance tests, or  produce useful user manuals, is unrealistic in most organizations: business stakeholders and development teams rarely have the time and the combination of competencies necessary to produce such deliverables with the velocity and quality that is needed for the project to succeed. Having a skilled business analyst responsible for creating the necessary documentation (or supervising the work of technical writers doing the work) minimizes the risk that such deliverables are not ready at the time they are needed, or lack the level of detail and quality required to achieve project goals.

Well developed business analysts can help agile teams in all aspects of communication, from selecting the documentation methods and formats that are most appropriate for the project, to producing quality documents and ensuring that the pieces of document are ready at the points of the project when they are needed.

Underperforming BAs need not apply

As with plan-driven organizations, mature agile organizations are always looking for ways to improve the performance of their software process. Optimization of the development process may require tailoring agile methods to the company’s needs and capabilities, and adding a talented BA to the team is becoming an obvious answer for many of the struggles that sometimes agile teams face, from competing interests among various stakeholders, to lack of a clear understanding of the problem to be solved with the software solution.

If a skilled BA will thrive in such environment, the same cannot be said about business analysts who lack facilitation and problem-solving skills, and generally don’t add value even to plan-driven projects. For BAs who consider their job just to record what the business stakeholders say and hand it to the developers, there will be no space in an agile team. On the other hand, a BA who is proactive, flexible, successful at working across organizational boundaries, and capable of responding positively to the challenges of building software in short iterations, won’t find it difficult to fit in as a valuable contributor to an agile project. Which one will you be?

Author: Adriana Beal has a B. Sc. in electronic engineering and an MBA in strategic management of information systems. For the past 10 years, she has been identifying business needs and determining solutions for business problems for a diverse client base that includes IT, telecom, and major U.S. financial institutions.

Article image © Yabresse - Fotolia.com

Like this article:
  31 members liked this article


SarahM posted on Tuesday, July 12, 2011 10:46 AM
I just wanted to comment that Xtreme programming and Agile are not one and the same thing, nor does Agile methods necessarily include Xtreme programming ideas. This article seems to imply that.

There's a book called 'Agile Requirements' by Dean Leffington, which a good source of ideas about how to do requirements in an Agile environment.
Mark Wavle posted on Saturday, July 16, 2011 8:26 AM
This article also serves as a great overview of the things a BA needs to consider when stepping into an Agile project. Facilitation is definitely key, and many "on the fly" things are dealt with in real time on Agile (or Agile-like) projects. This is quite a switch from Waterfall methods and is often the biggest headache a BA has when starting to work on an Agile team.

BA's, don't be afraid of Agile methodologies. You can bring a LOT of value to the project, even if you don't create a large requirements document! Keep the end goal in mind - working, valuable software - and you'll be surprised how much you can do to help the team meet that goal.
Adriana Beal posted on Saturday, July 16, 2011 6:04 PM
@sxminc: Indeed, I had no intention of implying that Xtreme programming and Agile are the same thing. Actually SCRUM is the most common agile approach the agile BAs I know work with, and I could have equally quoted from Dean Leffington or another agile specialist talking about SCRUM and saying the same thing I quoted. Thanks for pointing it out for anyone who might have gotten this wrong impression.

@mark: Thank you for your comment and encouragement for BAs switching to agile!

@JeffreyGoodReq posted on Sunday, July 17, 2011 8:46 PM
Thank-you, Adriana. In the end, I'd summarize your article by saying BAs make things happen. We are the problem-solvers both business and developers need. We must have strong communication, negotiation, and facilitation skills, or the process and product will suffer for our lack. The types and quantity of documentation change with the methodology in all methodologies, but the ability of a good BA to make a difference never changes.

I'd appreciate feedback on (My) BA Manifesto and how it fits in with your view.
Adriana Beal posted on Sunday, July 17, 2011 9:31 PM
@jdavidson: I think your manifesto is absolutely in the right direction -- thanks for sharing the link. Completely agree with BA being a distinct role that requires specific competencies for high performance and has a measurable value proposition.

I also like Laura Brandenburg's manifesto, which a commenter already mentioned there. I'm not very good at writing manifestos, so I can't think of any suggestions, but maybe more readers will see your link here and leave their comments at your blog to continue to evolve the idea.


zarfman posted on Saturday, July 23, 2011 1:21 AM

Many of the articles that I read including this one tend to describe BA’s as facilitators, problems solvers, skilled in the art of elicitation, etc.

I’m beginning to wonder if the term business analyst has become a meaningless catchall term.

The areas in which I have work and/or management experience, e.g. finance, accounting, etc we have various regulatory agencies. I shall mention three, the Federal Energy Regulatory Commission, or FERC, is an independent agency that regulates the interstate transmission of electricity, natural gas, and oil. The Financial Accounting Standards Board, or FASB, is the organization that establishes and communicates standards of financial accounting and reporting in the United States. FASB standards, known as generally accepted accounting principles (GAAP). Last but not least the IRS.

These miscellaneous and sundry regulations unfortunately, in many cases, leave room for interpretation and require specialized knowledge to interpret them. Such as CPA’s and Attorney’s who specialize in these areas. Large firms may have these specialists on staff; small firms usually seek outside assistance. We can ask the question, can these specialists be called BA’s?

I would suggest the vast majority of BA’s would find their skill set severely lacking in the forgoing areas.

Moreover, BA’s are only a part of the non-independent entities that comprise a project agile or not. Any one of these entities can destroy or cripple a project.

By the way, what technique do you use to optimize the development process? Also, how does one measure and minimize risk.


Adriana Beal posted on Saturday, July 23, 2011 4:02 AM
Zarfman, good to hear from you again :-). You never emailed me so we could plan our "book club", heh.

Anyway, when you say "Many of the articles that I read including this one tend to describe BA’s as facilitators, problems solvers, skilled in the art of elicitation, etc. I’m beginning to wonder if the term business analyst has become a meaningless catchall term.", here's what I think:

Facilitator / problem solver / specialized in elicitation perfectly describes my current role, as well as the one I held working for a NYC-based consulting firm for 5 years. However, as you've described, I've seen people performing all types of jobs being called a "BA", from Subject Matter Experts to administrative assistants. In that sense, what you say is true, it has become a "catchall term".

The IIBA (the International Institute of Business Analysis) is making an effort to define the role around the responsibilities discussed in my article, but that doesn't mean there aren't other definitions for "business analyst" out there.

In my current role of facilitator / problem solver / requirements elicitation specialist, my title is "IT Business Consultant", but I'm referred to as a "business analyst" when talking to business and technical teams.

Regarding your question, "By the way, what technique do you use to optimize the development process? Also, how does one measure and minimize risk", it would not possible to cover these topics in the small space here, but in my next article for Modern Analyst I'll be discussing your first question in the context of agile development. I hope you will join the conversation again once it's published!
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC