The Experts’ Take on Business Analysis and Agile


Are Business Analysts Obsolete in an Agile World?

Since the Business Analyst title (like many others) does not exist in most Agile or Scrum teams, does that mean that the Business Analysis skills are not needed? Our experts all indicated that having people with strong Business Analysts skills is still extremely essential to the success of a team or project. The removal of titles isn’t meant to indicate the devaluation those individuals, but rather to have people see beyond designations, credentials and classifications and focus on utilizing each person’s unique abilities and qualities to reach the goals of the team.

As Gottesdiener notes, “in some teams, analysis skills are shared among team members. That is more common in small teams working on small projects, when team members have rich business domain expertise or when there is an ‘uber’ Product Owner who has loads of skills to do the business analysis, and requirements skills for connecting multiple teams together to deliver the product.”

Most Agile teams are grateful to have people with deep business analysis talent, particularly those with fine-tuned facilitation skills, agile modeling skills, the drive to reduce waste (including unneeded documentation), and the ability to get requirements ready for upcoming iterations. Gottesdiener states that “Agile teams definitely need the skills and disciplines of business analysis. It varies from team to team whether those skills are embodied in a delivery team member, the customer, or a combination of people.

As a result you may find ‘Developers’ who help with writing user stories or interacting with customers, ‘Business Analysts’ who assist with designing a great user interface, or ‘Project Managers’ who will come up with acceptance criteria for test cases.

Cockburn notes that “the early attempts at Agile development tried to do away with the Business Analyst” because of the potential distortion of communication with a go-between. However, given the complexity of organizations, the disparate business languages that various units may use and the time constraints of subject matter experts, “more recent variations are finding good use for someone with deep business knowledge, who has time to spend talking with the programmers.”

Ambler states “it's still critical that analysis occur on an agile project, in fact it's so important we do it every single day of the project. BUT, that doesn't imply that agile teams need someone in the specific role of Business Analysis solely doing that sort of work.”

Schwaber believes that “every Scrum team needs people who understand the business domain. I would expect them to help everyone understand what is needed from a business point of view, to document these requirements as acceptance tests, to help the Product Owner groom and maintain the product backlog, and to work with the whole team all of the time.” Business Analysts with a deep knowledge of the business or market that the team is serving become essential to a team’s success.

Furthermore, the actual management of artifacts and requirements is still extremely important. Nee indicates that “an Agile setting does not eliminate the need for good quality requirements development. There is still a need for facilitation of requirements gathering sessions, analysis of requirements, elicitation of requirements, and the applicability of those requirements to the solution.”

While an Agile environment may introduce different tools, processes and even principles to a Business Analyst, the individual skills of that person can help them succeed in this new environment. Kohl mentions how a master welder can do anything with a gas welder. If the welder moves to a different shop in a different industry using different processes and a different tool, they can still provide value to the organization once he or she “learns how to use a new tool, and learn the new processes and procedures.”

While a Business Analyst may not carry a title in an Agile setting, they are still a valuable contributor to the team’s success. Ambler notes that “anyone transitioning from traditional to Agile must expect to make some changes. Whether they're threatened by that is up to the individual.”

Preparing to Join an Agile Team

Business Analysts who are about to embark on their first Agile experience may feel a little trepidation. Our experts indicated that the best way someone can prepare for it is to view the chance as an opportunity to learn. Ambler indicates that Business Analysts need “an open mind, be willing to learn new skills and to transfer your existing skills.”

Cockburn has 3 tricks for Business Analysts to get started on an Agile team:

  • “Learn to slice business requests into smaller requests that can be developed and delivered in smaller time units, and built up to create fully interesting business initiatives.

  • Learn to connect the development team more closely to the ultimate sources of business needs (often the business executives, the clients, or the system users on the client premises); and learn to connect the non-programmer people inside the business more closely to the clients of the business.

  • Learn to involve the clients directly in the development of the business itself, helping to frame the initiatives of the business so that the clients eventually co-steer those initiatives, even though those initiatives would look, in old parlance, as "internal" initiatives.”

Gottesdiener also has some helpful suggestions: “Open your mind. Be ready to relinquish control of the requirements. Relax the need to be a 'template zombie'.  ”Analysts who are “less focused on roles and job boundaries, and more focused on delivering customer value as a team” will thrive in an Agile environment.

Schwaber believes that the best way to get started in Agile is simple: “join”. Kohl also encourages on the job training. Once someone has learned the basics you should “take on a Scrum Master role and see what you think. I encourage experimentation. I work with a lot of teams, and they all look different, yet they are able to create value.”

Taking Agile out into the Organization

Business Analysts who become adept at Agile techniques and methods can help those inside and outside the organization understand how Agile can be leveraged. People who are only indirectly involved in Agile project may not understand the benefits of an Agile process. In particular, highly structured organizations with rigorous Project Management processes people may find an Agile approach haphazard and risky.

Schwaber indicates that “by joining Product Marketing and the customer organization, or by being a Scrum Master, the [Business Analyst can be a] pivot point for change.” Business Analysts can become a spokesperson and educate others in the goals, processes and benefits of Agile.

Pichler indicates that it is “the ScrumMaster’s job is to help Scrum be established in the organization, together with management.” However, at times the ScrumMaster’s ‘official’ title may not be considered ‘high level’ and as a result a Business Analyst may have more opportunities to communicate Agile within the organization.

Kohl cautions taking Agile beyond its aims within software development. Agile principles have been around in some shape or form for several decades and Managers may take issue with this ‘revolutionary’ concept. “There have been many similar movements in the business world that have had varying levels of success. Agile management sounds suspiciously like Total Quality Management repackaged.” Gottesdiener also notes how Agile is becoming part of the mainstream and a standard for software development. She notes that “people aren’t arguing very much about Agile. Most of the theoretical issues are settled. Now we’re focused on how to implement agile practices.”

Article Pages

Page: 3 Of 4First  Previous  1  2  3  4  Next  Last  
Like this article:
  1262 members liked this article


Dennis posted on Tuesday, March 9, 2010 10:45 AM
Each generation takes the best of the best and applies its own jargon to the title, related methodologies, policies, plans and processes. Each iteration is more collaborative with shorter and more iterations of its components. What varies in and between generations is the perserverance and genuine participation of the project stakeholders. The more the process is trusted, the more successful the project or program. Too often within or between generations, the respective "process" is not truly understood, the participants (stakeholders) not fully trained, and/or shortcuts are attempted (not doing or not doing fully what is to be done, not taking the necessary time, acceding to political or profit motivations and changing the project parameters). When allowed, properly trained people, properly resourced, are successful within any previously successful construct (repeatable methodology, plan, etc.). Agile, more than previous constructs, just emphasizes the increase in collaboration and iterations, and need to be able to produce subdeliverables while other subdeliverables and the main deliverable are still in flux. The difference, primarily between now and the past, is more of the team needs to be comfortable in the ambiguity of moving and constructing so quickly rather than just the leader(s). As that happens, more can be done more quickly. But as noted in the article, for some stakeholders, their specific roles may not change that significantly.
Roman Pichler posted on Tuesday, March 9, 2010 12:39 PM
You can read more about my thoughts on the role of business analysts on Scrum projects here:
Ellen Gottesdiener posted on Tuesday, March 9, 2010 9:59 PM
Good read by Roman! (his blog post, mentioned in the comment by him above).

Likewise, you can read more about my thoughts (my full answers to Jarett's questions in this two-part blog:


Roland Hesz posted on Wednesday, March 10, 2010 8:51 AM
"the emphasis is clearly shifted to ensuring that the people who need to meet the requirements understand them rather than having a pristine document that may not effectively communicate the information to the implementers. "

Maybe I worked in a weird environment, but while we never worked "agile", the above was true. We tried to work effectively.
Also, as a BA I was always in contact with the developers, no "hand over", I was actually sitting with them from the start of the project to the end.

Common sense can be found outside of "agile" too.
Tony Markos posted on Tuesday, March 16, 2010 9:42 AM
I feel that you missed the most important task of a BA on Agile projects. Agile projects require an up-front big picture. This big picture is used to, among other things, scope the project and to prioritize the individual iterations. Coming up with this big picture (in a just enough fashion) is by far the most important thing that a BA needs to do on an agile project. Funny that none of the "experts" sees such.

Ellen Gottesdiener posted on Tuesday, March 16, 2010 11:17 AM

The article author wrote a high level summary of responses he obtained from each of the interviewees. Given limited space, he could not incorporate all ideas and comments that each of us must have shared with him.

My guess is that is why you don't see points any of us may have made about "the big picture".

As for me, this is a key issue -- the "big view" --which i did bring up in my response to the interview question.

On agile projects, requirements and planning converge.

i discussed the need to have that "up-front big picture" in my blog post (the 2 part post contains my complete responses to Jarett's questions).

You can find my comment toward the bottom of that blog post where it reads, "Agile presents special requirements challenges" at this location:

and also in this article: for more.

all the best,

~ ellen
Roman Pichler posted on Tuesday, March 16, 2010 11:59 AM
After reading Ellen's excellent article "A View to Agile Requirements," you my want to check out my take on the big view / visioning work in Scrum:

If the visioning activities are carried out by the Scrum team, then a business analyst on the team would certainly be involved. The same is true if the business analyst plays the product owner role or if the individual is part of the product owner team.

Tony Markos posted on Tuesday, March 16, 2010 12:10 PM

Your past articles to the side, this article does not discuss what the most important contribution of a BA in an Agile project is: Coming up with a adequate (but just enough) big picture. And - especially in a high-level discussion - there should be a heavy focus on the most important thing that should be done.

The article mentions Cockburn as saying that Agile is a "priorities and values declaration..." So what are the BA responsibilities during an Agile project prioritized? The article mentions that Nee says that there is a need for BAs to gather requirements during the individual iterations, but the priority of that task is significantly lower than of that of coming up with the big picture.


Jarett Hailes posted on Wednesday, March 17, 2010 9:04 AM
Thanks everyone for the comments and to Ellen and Roman for their follow-up posts.

As Ellen mentioned I had a wealth of great responses from all the experts and could not incorporate all their details. Tony you are correct that I did not highlight the importance of having a clear initial scope in an Agile project, I apologize for this omission.

Personally, I don't believe that it necessarily falls to the BA to provide an up front picture. My belief is that the 'team' (not just the implementers but other stakeholders such as the sponsor or Product Owner) needs to come up with this picture collectively.

To place such a specific responsibility on one individual within an Agile project would tend to devolve people back into strict roles and responsibilities that could be a detriment the end goal, which is to deliver the best quality product or solution possible. What if a developer can articulate the big picture clearly? Or a tester? Or the manager who is ultimately repsonsible for the delivery of the solution? Should the BA insist on producing the document or descriptions for the product definition if there are others on the team who can do just as good of a job or better, because that's what BAs do?

While a BA likely has a good skill set to help guide the team to come up with the initial scope, but I would hesitate to prescribe that they are the sole person in a team who can perform this duty. If the picture is unclear or imprecise and the team is struggling to come up with a good description, then the BA should step up and help lead activities that will help the team come together on a good precise understanding of what needs to be done.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC