The Experts’ Take on Business Analysis and Agile


Differences in Documentation and Deliverables

One of the greatest differences of being on an Agile team for Business Analysts is the management of requirements. Analysts who are used to thick requirements documents or being the sole maintainer of such information within a requirements management software package will immediately notice the different approach to requirements elicitation, gathering, documentation and ongoing management.

Schwaber stressed that Business Analysts need to understand that they “come to play in a self-organizing team that communicates visually and verbally rather than by written documents.” While that doesn’t necessarily mean that there will be no documentation, 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. The Agile Manifesto principle of “working software over comprehensive documentation” is used to ensure that just enough documentation is created and maintained. This does not mean that the documentation should be incomplete or shoddy, but it should be concise and as accurate as possible at any given point in time.

Instead of a requirements document, Business Analysts may be writing requirements in the form of user stories, or they may be maintaining lists of functions, features, performance metrics, or some other relevant item. While some Agile teams may adopt a standard for documentation, others will adapt their documentation to meet the current needs of the team. For instance, user stories may be written for all software functions to be built, but in some cases a supplemental ‘spec/details sheet’ may be created for certain stories if more information is required than can fit on a 5 X 7 card.

Furthermore the documentation that Business Analysts write is unlikely to undergo a formal sign-off process. While input and clarity is essential, Agile teams rarely are looking for an official approval before going to use the documentation. Some Business Analysts may find the lack of comfort knowing that stakeholders have officially approved written deliverables a little disconcerting. However, if the team and the stakeholders the team serves can build a level of trust that allows for ongoing engagement and collaboration, the benefits to accurately delivering to the customer’s needs instead of a potentially antagonistic approval process can help the Business Analyst adapt to the situation.

Some Agile teams may take an extreme view of the Agile principles and not see the value in documentation. Kohl stresses that Business Analysts shouldn’t “be bullied into producing shoddy work just because the Agile team isn't familiar with your skills and tools. If this happens, overcome it by demonstrating how your work is helping the team create value, and how what you are doing is consistent with the Agile Manifesto, and is not threatening the process the team is depending on.”

For instance, Gottesdiener notes that “Agile presents special requirements challenges. Current lore about representing requirements as user stories does not directly address non-functional requirements (e.g. quality attributes and design and implementation constraints). Sharp Business Analysts can provide crucial help in eliciting and analyzing those important requirements.”

Business Analysts and the Product Owner Role

In the Scrum methodology there are only two specialized roles defined in the team: the ScrumMaster and the Product Owner.  The Product Owner is seen as the go-to person to understand customer requirements and is ultimately responsible for prioritizing the team’s product backlog.  Given a Business Analyst’s involvement in requirements management in traditional projects, this role could be one that is filled by a Business Analyst.

Pichler sees product backlog management as an important task where Business Analysts can be heavily involved; however “this task should be a team effort.” Schwaber believes that Business Analysts can have “a solid career path to leave IT and go into being a Product Owner in the customer organization or product marketing.”

Whether the Business Analyst should play the role of the Product Owner can depend on their expertise. Cockburn believes that if the Business Analyst is an “expert in the operations of the business”, then being the Product Owner is a natural fit.

Pichler does note that in a Scrum setting “getting direct communication established is, for me, the right way to get things going in an Agile world.” As a result the need for a dedicated Product Owner can be diminished in terms of representing a customer or stakeholder group. Pichler also cautions against having the Business Analyst play the role of a ‘proxy Product Owner’. He considers this an ‘anti-pattern’ of functioning Agile team that can have negative consequences for all involved. Pichler describes this anti-pattern in detail in his upcoming book, Agile Product Management with Scrum.

Pichler recalls how in one company “the Product Vice President was too busy to be the Product Owner, so the Business Analyst stepped in as a proxy. But authority was ultimately with the Product Manager”. This led to a frustrating experience for everyone as decision making was delayed, communication lines were broken and the team did not have a clear vision for the product.

Gottesdiener believes that “the Product Owner must conduct a mix of strategic and tactical activities. This takes a lot of knowledge and many skills, and it consumes a lot of time.” Seldom does a single person have the ability to fulfill all aspects of this demanding role and as a result “many organizations turn to talented Business Analysts for help with the day-to-day, tactical decision making on their Agile projects. In other cases, someone who was formerly a traditional Business Analyst will work out the backlog items, suggest the priorities, and then obtain validation from the business Product Owner.”

Ultimately, the Business Analyst may be the best choice for Product Owner on a Scrum team, but it does depend on the environment and the other individuals involved in the process.

Other Activities Business Analysts Perform in an Agile Team

As noted above, Business Analysts may find themselves participating in other activities that they may not be accustomed to. In addition to writing user stories, Business Analysts may write acceptance tests, user documentation, or work with more technically-oriented individuals to help with documenting the system itself.

Because Business Analysts typically have strong communication skills, they can play an important part to help get the rest of the team get comfortable with its stakeholders. If other team members are new to Agile they may not be used to the open lines of communication between the team and outside personnel. The Business Analyst can help ensure that there is ongoing and meaningful two-way communication to help ensure the team is meeting the customer’s needs.

The Business Analyst can also help facilitate sessions within the team as well as with outside stakeholders. If the team is using Scrum then the ScrumMaster will manage the regular meetings a team holds (daily stand-ups, demos, retrospectives and planning sessions). As a team member the Business Analyst should look to support the ScrumMaster as needed and help identify potential issues as they arise to ensure the team is working as efficiently as possible.

Article Pages

Page: 2 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