3 Things Every Business Analyst Should Know about Agile


In the past few years, software development has been shifting more and more from traditional to agile practices. This change impacts how business analysts perform their role. Here are three key aspects of the business analysis work that are different in an agile environment:

  1. The BA becomes a key player in avoiding costly software architecture problems

There are many definitions of “software architecture”. For the lack of a universal description, I’ll use here one that I think reflects the intention behind the many proposed definitions listed in the book Documenting Software Architectures: Views and Beyond: software architecture is the set of significant decisions about the organization and interaction of the components of a software product used to govern its design and evolution over time. As explained in the prologue of the same book,

Architecture is what makes the sets of parts work together as a coherent and successful whole.

The purpose of software architecture is to ensure that the software product satisfies the system’s quality and behavioral requirements. Successful software products have a solid architecture behind them, capable of addressing all the functional and quality attributes required to fulfill the business need.

When a BA works in a traditional software project, he or she is expected to detail the majority of the requirements up front, making available to the system’s architect all the information needed to understand and support the business goals. Agile projects, on the other hand, emphasize the incremental delivery of client-specified features. While slicing off a set of features for earlier release may prove beneficial, the lack of full visibility into the overall requirements as the initial architecture is defined often cause issues related to system behavior, performance, scalability, maintainability, or other crucial attribute. Such problems typically require costly rework to retrofit important capabilities that weren't identified until the project is halfway. As pointed out in the book Making Software: What Really Works, and Why,

Many agile projects succeed by doing a lot of architecting, but spreading it out across the life cycle through re-factoring. This is an effective process as long as the project stays small and noncritical, but can run into “easiest-first” difficulties otherwise.

To avoid the problems caused by poor architecture decisions that cannot be easily undone by re-factoring, a BA working on a complex agile project must work extra hard to make sure the high-level requirements are properly identified early on. In contrast to a traditional project, an agile project poses a substantial risk that the team will move too quickly into iterative design and implementation, before the critical aspects of the solution are sufficiently understood to support the right architecture decisions.

Even though in an agile project the expectation is that requirements will be defined closer to implementation (in a “just-in-time” manner), if crucial aspects of the system aren't acknowledged during the early stages of the project,chances are that one or more important quality attributes will be ignored and become incompatible with the initial architectural commitments. Here are two real-life examples that could have been avoided by more investment in upfront requirements analysis:

  • In a system that needed to store information about both suppliers and customers of an organization,the BA failed to determine early on that the same company might be listed both as a supplier and a customer. The late discovery of this requirement made it impossible to implement an optimal solution, demanding instead the use of an undesirable workaround that required the duplication of entries for the companies that had a dual relationship with the organization.

  • In an e-commerce back-office system, the implementation of features was initiated before some of the non-functional requirements were well understood. As a consequence, the team made architecture choices that allowed the right functionality to be produced, but impeded the expected security control structures to be implemented. Expensive re-factoring was required to ensure that the ability to perform certain operations was restricted to specific roles, as demanded by the compliance group.

Agile approaches emphasize the practices of minimizing unnecessary planning and documentation, and a big challenge for a BA working on an agile environment is to learn how to effectively distinguish an early analysis effort that is “unnecessary” from what’s crucial to avoid the risk of wrong architecture decisions that cannot be easily undone.

2. Business analysis skills are critical to ensure the right bundle of features is selected for each release

When releasing software incrementally, it’s important to choose the right batch of features that is both high-value and immediately useful. In theory, product owners, business stakeholders, and/or end-users should be able to make the right decisions about which features will deliver the most value in the next release. In practice, however, it’s common to see agile releases that incorporate the highest value features and still don’t enable users to achieve their goals. This issue happens largely as a result of the phenomenon of bounded rationality: a few supporting features that didn't make the cut turn out to be essential to make the release truly useful to those trying to accomplish a goal with the software.

Take for example the construction of an online store.Stakeholders could very well assign a much higher value to the checkout process than to the ability to estimate shipping costs before placing an order. If, however, the products being sold are typically large and heavy, thus incurring significant shipping costs, customers may be reluctant to create an order before checking the final price. Under these circumstances, a release that enables checkout, but does not support shipping cost estimation, may not be the best use of the available resources. It might be better to postpone another high-value feature, such as the offer of additional payment methods, in order to include in the release what could be considered a lower value feature, but that in practice represents an important supporting capability to convince customers to buy.

When stakeholders are prioritizing features, the business analyst must be able to step forward and help them use their best judgment to decide what features make up an optimal release. By asking the right questions, the BA can help the decision-makers understand not only what features will provide the highest value, but also what additional capabilities must be included to complement the most valuable features, in support of a particular type of user or business process. This is one of the most valuable contributions of a BA in an agile project: to ensure that along with the highest value features, a release incorporates all the surrounding functionality required for the new capabilities to be truly useful to the people who ultimately receive them.

3. Test analysis and design skills take a front seat in the BA role

BAs working on agile projects are more effective when they display solid knowledge of how to create quality acceptance tests that successfully cover all dimensions of the behavior and quality of software produced in short releases cycles.

In agile approaches, test analysis and design are essential components of the requirements analysis and system specification process. Acceptance tests often serve as the specification of what is required of the software, and may be captured as executable test scripts in some documentation/testing tool. When part of an agile team, the BA must be able to work with various constituents: the product owner, developer, tester, UI designer, to define effective acceptance tests for the user stories covered in each sprint or iteration.

Author: Adriana Beal spent the past 10 years consulting for Fortune 100 organizations implementing large, complex software projects. She currently works as a product manager for an enterprise-grade software-as-a-service application at Spredfast in Austin, Texas. Opinions expressed are solely her own and do not express the views or opinions of her employer.

Posted in: Agile Methods
Like this article:
  30 members liked this article


ron segal posted on Tuesday, July 15, 2014 6:21 PM
Adriana, an excellent article which very much fits my own experiences, particularly your first two points in particular, which can be the difference between success and absolute disaster.


'.. a BA working on a complex agile project must work extra hard to make sure the high-level requirements are properly identified early on.'

I agree, but what does 'work extra hard' actually mean?

Irrespective of 'agile', a big picture design (aka architecture) is essential, unless it is a very small development. Producing this is a perfect role for an analyst/architect. So for me, 'agile' implies such an emerging role. Or perhaps it is just a new version of the old 'systems analyst' wheel coming around again!
Duane Banks posted on Wednesday, July 16, 2014 9:43 AM
Good article, Adriana!

Ron, based on the article's message, I think "work extra hard" refers to cultivating a collaborative effort.

Collaboration underlies Adriana's first two points.

Adriana, love the quote, "Architecture is what makes the sets of parts work together as a coherent and successful whole."

I would add that "a successful and coherent whole" is reliant upon assessing and framing an understanding of the whole. Architecture is subsequent to "assessing and framing."
Duane Banks posted on Wednesday, July 16, 2014 9:44 AM
Duane Banks
genevieve mcculloch posted on Wednesday, July 16, 2014 2:51 PM
In the first example, you mentioned that 'the BA failed to determine early on that the same company might be listed both as a supplier and a customer.'....wouldn't this be a a business rule, that a company can be both a supplier and a customer?

If not, how would you would word the business requirement? i'll take a stab at the functional requirement -'The solution must be able to accept a company name as both a customer and supplier'. Any thoughts? thanks
ron segal posted on Wednesday, July 16, 2014 4:26 PM
Duane, stimulating collaboration is important but entirely insufficient to ensure that a suitable architectural specification is created. The only way to ensure the latter is to drive it. Particularly with the shift to agile methods, in my view this is the most fruitful way for business information systems analysis to be heading.

Mccullog, Adriana's customer / supplier example is a simple but good one. Where the approach is entirely by 'stepwise refinement' (the essence of agile) the discovery of structurally significant rules can come too late, when a heap of work has already been done that assumes something different.

Duane Banks posted on Wednesday, July 16, 2014 5:11 PM
Ron, I'm interested in learning more driving it. Please elaborate, or provide a link if you know if one.
Leslie posted on Wednesday, July 16, 2014 5:34 PM
These are great points, and all identified by the Rational Unified Process nearly 20 years ago, long before Scrum became popular in the workplace.

But Agile doesn't need to consider Roles such as business/systems analyst as defined by a heavyweight method such as RUP - or does it.

My advice; if you want to learn more - pick up a copy of the RUP and read the activities played by the analyst roles.
ron segal posted on Wednesday, July 16, 2014 5:59 PM
Duane, what I mean by 'drive' is lead, particularly in the sense of thought leadership. So for example, DSDM is a well proven approach to large, agile software development (http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method). So the (senior / principal) business information systems analyst is (should be) well placed to lead the Feasibility and Business studies as well as the development of the (conceptual) software architecture.

Adriana Beal posted on Wednesday, July 16, 2014 8:51 PM
Thank you, everyone, for the excellent comments!

@DivisionOne - Indeed, a collaborative effort is critical. We want the business, engineers, analysts, UX designers all working together to understand the big picture and help identify better solutions that aren't focused just on a specific sprint / iteration.

@RonSegal: "Irrespective of 'agile', a big picture design (aka architecture) is essential, unless it is a very small development." I'm in total agreement, but see, what I wanted to highlight is that agile processes, compared to traditional development models, tend to focus much more on the "here and now" (individual user stories), making it easier to ignore the not-visibly-urgent, yet still important big picture, until it’s “too late”. That's why, in my opinion, the BA has to work harder in agile projects to make sure all important aspects of the overall solution are understood at the appropriate level at the early stages. In traditional sw development, the BA is expected to spend more time upfront doing analysis anyway, so it's easier to dedicate the necessary effort to develop that early understanding. In agile projects, there's much pressure to start building the solution as soon as the first stories are written. Convincing business and technical stakeholders of the value of the discovery process beyond the initial features typically require extra work on the part of the analyst.

Adriana Beal posted on Wednesday, July 16, 2014 9:14 PM
@ mccullog
"In the first example, you mentioned that 'the BA failed to determine early on that the same company might be listed both as a supplier and a customer.'.... wouldn't this be a a business rule, that a company can be both a supplier and a customer? "

I don't know that I'd capture this as a business rule. (Just imagine having to capture everything that's possible in real life, and your solution needs to support, as business rules: "a customer can have more than one shipping address", "a parent can have more than one child", etc.).

To me, a great way to surface the need to support the same company being assigned the roles of customer and supplier would be to create a fact model like this one from Ross' book: https://flic.kr/p/5xJprN. With a a diagram like this, it would have been easy for the BA to identify this scenario as one that would need to be supported by the solution. Then it becomes a requirement to be fulfilled (which could be described as a textual statement, or reside in the visual model).
ron segal posted on Wednesday, July 16, 2014 9:50 PM
Adriana, we're certainly agreeing on the need for an up-front, big picture understanding on agile developments.

This includes such things as significant business rules, conceptual components (or functions) and their dependencies, which can be expressed in a conceptual architecture (big picture blueprint).

What I'm suggesting is that such architectures are better developed by architects who are also business analysts (and the corollary). In which case there's much less need for the (current stereotype) of 'business analyst' on agile projects (other than in support of your third point). This doesn't mean a dead end for business analysis, far from it, rather it implies a shift in boundaries and knowledge.
ron segal posted on Wednesday, July 16, 2014 10:10 PM
Adriana, the 'facts model' (effectively a key concepts map), or similar, I have always found to be an essential starting point for almost any information systems development and indeed more general business development (for e.g. business process design). Creation of this kind of model typifies why I see the need for crossover between current stereotype business analysis and business/ information systems architect.
Adriana Beal posted on Wednesday, July 16, 2014 10:42 PM

It looks like we agree in principle, and only have a difference in terminology. I've always considered the creation of "fact models" (or concept maps) the domain of the business analyst, while the actual solution architecture would be the responsibility of a system architect.

I've never worked with a system architect that actually wanted to perform the requirements discovery process (they are typically busy with other projects, and grateful to have a BA go through the back and forth with business stakeholders to truly understand the problem to be solved and identify the characteristics of the right solution).

Likewise, I never felt comfortable with going beyond relationship map / context diagram / functional requirements and other artifacts describing the attributes of the desired solution. At that point, not only the system architect, but others would start to get involved -- such as a data modeler, UX designers, and ideally a team in charge of producing a prototype that can be tested on real users, and iterated upon. Having said that, if someone feels capable of doing well the roles that I divide between BA vs. architect, more power to them :-).
genevieve mcculloch posted on Wednesday, July 16, 2014 10:49 PM

What Ross is calling a 'fact model catalogue' looks like a data model from my old systems analyst days. Nothing new under the sun. I created one of these models on a contract job and the customer thought it was a complete waste of tme. It was the only way that I could learn the data model before documenting the business process.
Adriana Beal posted on Wednesday, July 16, 2014 11:04 PM
@Mccullog -- I'm used to making a distinction between concept / fact models and a data model like this: http://www.crwr.utexas.edu/gis/gishydro06/ODM/ObservationsDataModel_files/image003.jpg

As for "nothing new under the sun", I think we can all agree that most of the techniques we use today have been around for a long time. I like to use the term "fact model" because I find it helpful to disambiguate from other visual models, as I've noticed that different people will call distinct models by the same name.
Duane Banks posted on Wednesday, July 16, 2014 11:31 PM
For what it's worth, my earlier statement "assessing and framing an understanding of the whole" pertained more so to business architecture than systems architecture.

ron segal posted on Wednesday, July 16, 2014 11:39 PM
Adriana, the efficiency of agile developments of course hinge on a much more direct relationship between customers/users and developers. Consequently there is an argument (and often pressure) to collapse typical waterfall style roles and indeed also to minimise the chain of dependent artefacts. The resulting increased risk requires particularly able (more costly) people with broad skills and experience. Effectively the price of successful agility.
simeun posted on Thursday, July 24, 2014 8:53 AM
Adriana, very good article!
You identified some very important issues of iterative software development. Certain amount of up-front work can not be avoided, no matter how "agile" you are or want to be - key concepts (for example, company, buyer, supplier) and relations between them (a buyer IS a company, a supplier IS a company) should be recognized up-front...
Regarding business rules, there are various kinds of business rules and relations between concepts is one of them. It need not be stated in the form of business rule - it can be stated in the form of conceptual model, for examlple.
Adriana Beal posted on Thursday, July 24, 2014 3:54 PM
@divnasimeun - Thank you for leaving your comment. I'm glad we share the same view.

Agile teams that recognize the importance of balancing agility with a level upfront analysis to understand the relationships between system components and the overall user interaction end up not only with a better product, but get there faster too. This is because you don't have as much rework caused by too much focus on individual stories at the expense of the overall picture. Context diagrams / fact models are great tools to help audiences understand the big picture.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC