Agile Analysis

by Scott W. Ambler, Copyright 2002

Table of Contents

What is Analysis?
Rethinking the Role of Analysts
o The Traditional Activities of an Analyst
o Analysis Gone Awry
o Towards Agile Analysts
What is Agile Analysis?
Potential Analysis Artifacts
Conclusion
Acknowledgements
References and Suggested Reading

1. What is Analysis?
The purpose of analysis is to understand what will be built, why it should be built, how much it will likely cost to build
(estimation), and in what order it should be built (prioritization). This is similar to requirements elicitation, the purpose of which
is to determine what your users want to have built. The main difference is that the focus of requirements gathering is on
understanding your users and their potential usage of the system, whereas the focus of analysis shifts to understanding the
system itself and exploring the details of the problem domain. Another way to look at analysis is that it represents the middle
ground between requirements and design, the process by which your mindset shifts from what needs to be built to how it will
be built.
I begin this essay by arguing that the role of analysts on software development projects needs to evolve. A discussion of what I
believe agile analysis is follows, and finally I suggest modeling artifacts appropriate to agile analysis efforts.

2. Rethinking the Role of Analysts

Many organizations have an IT role called analyst, and will often differentiate between various types:

Requirements analysts who are responsible for requirements elicitation

Systems analysts who are responsible for analyzing the requirements to determine the system needs to fulfill those
requirements
Business analysts who are responsible for understanding the business and making recommendations for improvement
Business system analysts whose responsibilities are a combination of those of a requirements analyst, business
analyst, and a system analyst.

The focus of this discussion is on business system analysts (BSAs) even though many of the issues (or flavors
thereof) are pertinent to the other analyst types. BSAs typically have experience in a wide range of techniques,
including interviewing, structured meeting approaches such as Joint Application Development (JAD), modeling
sessions, and model reviews. Good BSAs have a good understanding of the business domain and are typically
people persons.
Why have many organizations adopted the idea of having BSAs on staff? The general reasoning is that developers
dont have the communication and modeling skills necessary to elicit requirements effectively, and sometimes they
dont even have the inclination to do so. Furthermore our project stakeholders typically dont have the skillset
necessary to effectively document their own requirements and therefore need someone to guide and facilitate their
efforts. It is unreasonable to expect everyone to be an expert at every aspect of software development, so having a
role that specializes in business analysis made a lot of sense.
Lets begin by exploring in detail the types of activities that a BSA traditionally performs on a software development
project. This will provide a basis from which we can examine the effectiveness of a BSA and then provide
suggestions for how BSAs fit into an agile software development project.
2.1 The Traditional Activities of an Analyst

A BSA on a traditional software development project will perform one or more of the following activities:
1. Scope the system. During the initial phase of a project, often called iteration zero or simply the inception
phase, BSAs may be the only development staff assigned to the project. At this point they will work with
key project stakeholders to formulate and communicate the business vision, to gather initial requirements,
and to scope the project. Their fundamental goal is to get the project focused early by translating the initial
high-level vision into something realistic. They may also help to identify potential areas of automation and
even to aid in reengineering the underlying business process.
2. Translate business needs. A major responsibility of BSAs is to work with project stakeholders to translate
their requirements into something that developers can understand as well as to translate the resulting
questions that the developers have into something the stakeholders can understand. This is an iterative
process throughout the project. An important part of this is to the distillation of the differing messages of
various project stakeholders into a single, consistent vision. This task often includes significant negotiation
and political maneuvering. In this respect a BSA will act as a knowledge integrator. Furthermore, BSAs
often find themselves spending significant time in meetings, thereby saving the rest of the development team
from this inefficient use of their time.
3. Translate technical issues. BSAs will also explain technical/architectural complexities to project
stakeholders, such as why your HTML-based application cant have as slick of a user interface as a Visual
Basic application. BSAs often explain what the developers are doing and why they need to do it, including
explanations of the basis of schedules and estimates.
4. Model and document. BSAs will often work with project stakeholders to identify, model, and then
document their requirements and business domain details.
5. Act as a communication broker. BSAs typically have very good connections within the business
community and therefore are in a position to help development teams find the right people to work with.
6. Political mentor. BSAs often help project teams through the political minefields within their organizations,
particularly when the BSA has worked within the same organization for several years.
7. Test and validation. BSAs will work with project stakeholders to validate their requirements and analysis
models via techniques such as reviews, walkthroughs, and play acting. BSAs will often aid in writing user
acceptance test (UAT) cases and will be a liaison between project stakeholders and your testing organization
during UAT.
8. Represent stakeholders. When project teams dont have direct access to their project stakeholders, clearly
not a good situation, BSAs will act as stakeholder surrogates. Typically developers will treat a BSA as the
customer from which requirements, domain information, and business priorities are provided. The BSA in
turn will work with the stakeholders to obtain information and to verify decisions.
2.2 Analysis Gone Awry
In theory the idea of having traditional BSAs involved with a project should work quite well, and in practice it often
does. The best analysts are organized and great communicators, having the ability to distill the critical information
from your project stakeholders out of the information noise that they provide often through a wide range of
modeling techniques. For many organizations the addition of BSAs clearly improved the quality of the requirements
elicitation and analysis modeling. It also opened up communication between the tech weenies in IT and the
business morons that the system was being built for.
Clearly this was a step in the right direction. However, some very common problems have been known to occur:
1. BSAs can lack the right skills. Many organizations have difficulties hiring the right people and/or nurturing
the right skills in people. The end result is that people are often thrust into the role of BSA but do not have
the skills to fulfill that role, nor do they have an opportunity to gain those skills.
2. BSAs can have undue project influence. A strong-willed BSA may inadvertently influence a project, perhaps
by playing down requirements that they dont agree with or even influencing architecture decisions by being
biased towards one type of analysis technique (such as focusing just on use cases or just on data models).
This is particularly dangerous when BSAs act as stakeholder surrogates AND the developers and
stakeholders have little interaction other than via the BSA.
3. BSAs can be out of date. Having previous development experience is critical for a BSA because it grounds
them in reality. However, it may also lead them astray. For example someone with a data-intensive
background may struggle when working with a development team that is using object technology (and vice
versa) because they dont know which issues they need to focus on.

4. BSAs can act as a communication barrier. Although BSAs can act as a communication bridge between the
two groups they also act as a communication barrier. On the Agile Modeling (AM) mailing list Ron Jeffries
depicted the communication approach of traditional BSAs to look like stakeholder => BSA => developer
=> BSA => stakeholder. This looks a lot like the game of telephone tag, doesnt it? When you play this
game you quickly discover that the signal degrades between hops, decreasing the chance that the actual
message gets through successfully. Although a highly skilled BSA, one with excellent communication skills,
will reduce this problem it will never go away completely.
5. BSAs can reduce stakeholder influence. An interesting implication is that your project stakeholders dont
have as much influence over the software as they may think. Theyre influencing the traditional BSA, and
the models and documentation that the BSA creates, but have no direct influence over what the developers
are creating. This can even be said of user interface prototyping efforts, particularly when those efforts are
led by a traditional BSA.
6. BSAs often over analyze. Another inherent problem with traditional BSAs is their tendency to actually do
their perceived jobs. What? When you specialize in something you will naturally focus on that task. The
implication is that the task of business analysis will be stretched out, instead of Iterating to Another Artifact
as AM suggests, such as a design model or even source code, a BSA will likely focus on expanding the
artifacts that they specialize in. Not only is your development effort likely to devolve into a more serial
process, instead of an iterative and incremental approach as suggested by the Agile Alliance, the BSAs are
likely to develop more documentation than is required.
7. BSAs can reduce feedback. When analysts are only responsible for analysis efforts, for creating models and
documents that are meant to be handed off to developers, there is less opportunity for feedback. There is the
danger that they will create theoretically sound models, and make unrealistic promises based on those
models to your project stakeholders, that dont work in practice. The feedback of people working with
software is critical, feedback that you cant get from models and documents. The BSA quickly learns what
actually works, and from the resulting changes requested by stakeholders quickly improves their analyst
skills because they recognize mistakes they made.
8. BSAs can reduce opportunities for developers to gain communication skills. With traditional BSAs in place
developers arent given as many opportunities to improve their own communication skills, skills that are
critical to success in todays environment. Nor are they given the opportunity to work closely with business
experts, opportunities that would allow them to learn about the nuances of the business environment and thus
increase the chance of them building a system that actually meets their users needs. Nor are they given the
chance to discover that the business morons are actually pretty smart after all, with interesting knowledge
worth learning. Similarly, project stakeholders miss the opportunity to learn about how software is
developed, arguably a good thing in some organizations, and to discover that the tech weenies are actually
very interesting people. Houston, we have a problem.
2.3 Towards Agile Analysts
Fundamentally the activities performed by traditional BSAs are varied, but a crucial goal was always to improve the
communication between developers and project stakeholders. In many traditional organizations that meant that
BSAs formed a bridge between the two groups, a definite improvement in many situations, although at the same
time erected barriers. Now is the time to take the next step, to become more agile and have BSAs become the
communication mentors/coaches on project teams. This isnt to say that every existing BSA is qualified to become a
communication mentor, but chances are that your pool of BSAs is a good place to start looking for likely candidates.
How can BSAs become more effective? AM suggests that development teams follows the practice Active Stakeholder
Participation, that they work closely with their project stakeholders. The goal of this practice is to reduce the feedback loop and
thereby improve communication. However, the way that you work with your stakeholders will in part be determined by your
teams organization. An interesting implication is that the role that a BSA takes on changes dramatically based on the
communication options available to your team. There are three categories of team organization that need to be considered
with respect to how an Agile BSA will act on a project team:
One room Developers and Stakeholders are Co-Located
Over the wall Single Location But Not Co-Located
Across the network Dispersed/Distributed Development

2.3.1 One Room Developers and Stakeholders are Co-Located

First, lets assume that you are able to co-locate your development team with your project stakeholders, an ideal
situation that you should always strive to achieve. In this situation an agile BSA should be just another one of the

developers on the team, likely leading requirements and analysis modeling efforts as needed. They would actively
work to facilitate communication within the team, mentoring developers in BSA skills and perhaps even mentor
project stakeholders in development skills. Ron Jeffries (2000a) says it well in his article Business Analysis in Extreme
Programming:
This begins with a simple change of focus, from "We'll go out and find out what the customers want
and bring it back", to "We'll go help the customers figure out what they want, so they can tell us".
This change of focus leaves control in the hands of the customers, and makes all the difference.
A critical skill that an agile BSA brings to the table is the ability to investigate and understand how the business
actually works, as opposed to how developers think it works or want it to work, an ability that they should be able to
mentor developers in. When co-located, Agile BSAs would also perform non-BSA activities as well, perhaps pair
programming with one of the developers on some of the business code or working with users to develop acceptance
tests. This way the agile BSA would grow his or her own skill set over time and would help others to do so as well.
An implication of this approach is that the traditional BSA is getting dropped in favor of a developer with very
good communication skills. This reflects AMs philosophy that good developers are Generalized Specialists,
people who have a general understanding of the complete software development lifecycle and one or more
specialties: in this case business system analysis. The danger of this approach is that the BSA cant be in the role of
conflict arbiter when developers and stakeholders dont see eye to eye the BSA is a developer and therefore is
likely to be seen as biased in such situations. Conflicts would need to be resolved by the project manager/coach or
one or more senior project stakeholders.
2.3.2 Over the Wall Single Location But Not Co-Located
A common situation is for project teams and project stakeholders to be located in the same building but not together
perhaps the project team is one floor and the stakeholders are on different floors. Furthermore, the project
stakeholders are typically not available on a full time basis to the project team. Common scenarios include
stakeholders that can co-locate one or two days a week and be available as needed on other days; stakeholders that
can be available for physical and teleconference meetings several times a week; and stakeholders whose availability
is severely limited and often can only give you an hour or two a week. Clearly none of these scenarios are ideal, but
unfortunately they are all too common.
In these situations the Agile BSA takes on some of the aspects of a traditional BSA. In particular, in situations
where the stakeholders are not able to partially co-locate with the development team the BSA will need to work with
them in their own environment. This will likely entail modeling sessions and interviews with the project
stakeholders. The Agile BSA will typically bring one or two other developers with them to these sessions, that way
the developers can not only learn the business knowledge that they need they can also gain BSA skills in the
process. This will also help to build bonds between the developers and stakeholders.
2.3.3 Across the Network Dispersed/Distributed Development
In this scenario the project team is located in a different location than their project stakeholders, and in the extreme
the project team itself is in several locations as are the project stakeholders. Large organizations, consortiums of
organizations, and organizations that outsource development to other companies (often overseas) often find
themselves in this situation. I highly suggest that you avoid distributed development situations such as this because
of the increased communication risk inherent in this approach. When a team is dispersed/distributed the
opportunities for face-to-face discussion, the most effective way to communicate, are reduced. Instead you are
forced to rely on less productive communication strategies such as video conferencing, telephone conversations,
and written documentation and thereby dramatically increase project risk. Rich communication between
developers and project stakeholders is a fundamental aspect of agile software development. It is possible to take an
agile approach in these situations, as Alan Wills (2002) describes in Dispersed Agile Software Development and Dispersed
eXtreme Programming, but its very hard.
In this situation the role of an Agile BSA devolves into something closer to that of a traditional BSA, that of trying
to bridge the gulf between developers and project stakeholders. They would realize that this situation is not in the
best interest of the project, that they really want to have the project stakeholders working with the developers and
therefore should try to get these people together as often as possible. Perhaps theyll facilitate conference calls,

video conferences, and online meetings between the two groups. Perhaps theyll help to arrange periodic colocations where some project stakeholders travel to the developers, or vice versa, to enable some direct interaction
between the groups.

3. What is Agile Analysis?

Lets begin by describing what agile analysis isnt:

It isnt a phase of your project

It isnt a task on your project schedule
It isnt a means unto itself

What is agile analysis? From the previous discussion of what an agile business system analyst does, your agile
analysis efforts should exhibit the following traits:
1. Agile analysis should be communication rich. Agile developers prefer warm communication techniques
such as face-to-face discussion and video conferencing over cold techniques such as documentation and
email (Cockburn 2002, Ambler 2002), as described in the Communication essay. Agile developers prefer to
work as closely as possible to their project stakeholders, following AMs Active Stakeholder Participation
practice wherever possible.
2. Agile analysis is highly iterative. As Martin (2002) points out analysis and design activities both rely on each
other: estimating is part of analysis yet that relies on some design being performed to identify how
something could be implemented and your design efforts rely on sufficient analysis being performed to
define what needs to be built. Hence analysis is iterative.
3. Agile analysis is incremental. Martin (2002) also correctly points out that agile analysis is incremental, that
you dont need to build systems all in one go. This philosophy supports the incremental approach favored by
common agile software processes where the work is broken done into small, achievable chunks of
functionality. These chunks should be implementable within a short period of time, often as little as hours or
days.
4. Agile analysis explores and illuminates the problem space. Your primary goal is to identify and
understand what your project stakeholders need of your system. Furthermore, this information needs to be
communicated to everyone involved with the project, including both developers and stakeholders. This
promotes understanding of, and agreement with, the overall vision of your project.
5. Agile analysis includes estimation and prioritization of requirements. It is during estimation and
prioritization of requirements where software development becomes real for project stakeholders. It is
very easy to say that you want something but much hard to agree to a price for it, let alone to trade it off for
something that is immediately more important to you.
6. Agile analysis results in artifacts that are just good enough. If any artifacts are created at all as the result
of your agile analysis (youll be following the AM practice Discard Temporary Models after all) they should
be either agile models or agile documents. Such artifacts are typically far from perfect, they just barely
fulfill their purpose and no more.
Here is my definition for agile analysis:
Agile analysis is highly iterative and incremental process where developers and project stakeholders actively work
together to understand the domain, to identify what needs to be built, to estimate that functionality, to prioritize the
functionality, and in the process optionally producing artifacts that are just barely good enough.

4. Some Potential Analysis Artifacts

Are the artifacts created taking an agile approach to analysis any different than the ones created as the result of
traditional analysis? In a way they are. They are in fact the same types of artifacts, a use case diagram is a use case
diagram after all, but the way in which they are created are different. The artifacts are created following the
principles and practices of AM, they are just barely good enough and are often discarded so as to travel light.

lists common artifacts used during analysis modeling and suggests a simple tool with which you could create
such an artifact. It is interesting to note that this list is meant to be representative, a more thorough list is presented
in the essay Artifacts for Agile Modeling and in the book Agile Modeling (Ambler 2002).
Table 1

Table 1. Candidate artifacts for analysis modeling.

Artifact

Simple
Description
Tool
Activity Diagram
Whiteboard UML activity diagrams are used during analysis modeling to explore the logic of a
usage scenario (see below), system use case, or the flow of logic of a business
process. In many ways activity diagrams are the object-oriented equivalent of flow
charts and data-flow diagrams (DFDs).
Class Diagram
Whiteboard Class diagrams show the classes of the system, their inter-relationships (including
inheritance, aggregation, and association), and the operations and attributes of the
classes. During analysis you can use class diagrams to represent your conceptual
model which depict your detailed understanding of the problem space for your
system.
Constraint
Index card A constraint is a restriction on the degree of freedom you have in providing a
definition
solution. Constraints are effectively global requirements for your project.
CRC model
Index cards A Class Responsibility Collaborator (CRC) model is a collection of standard index
cards, each of which have been divided into three sections, indicating the name of
the class, the responsibilities of the class, and the collaborators of the class. Like
class diagrams, CRC models are used during analysis modeling for conceptual
modeling.
Data flow diagram Whiteboard A data-flow diagram (DFD) shows the movement of data within a system between
(DFD)
processes, entities, and data stores. When analysis modeling a DFD can be used to
model the existing and/or proposed business processes that your system will
support.
Entity/Relationship Whiteboard E/R diagrams show the main entities, their data attributes, and the relationships
(E/R) diagram
between those entities. Like class diagrams E/R diagrams can be used for
(data diagram)
conceptual modeling, in many ways E/R diagrams can be thought of as a subset of
class diagrams.
Flow chart
Whiteboard Flow charts are used in a similar manner to activity diagrams.
Robustness
Whiteboard Robustness diagrams can be used to analyze usage scenarios to identify candidate
diagrams
classes and major user interface elements (screens, reports, ...).
Sequence diagram
Whiteboard Sequence diagrams are used to model the logic of usage scenarios. Sequence
diagrams model the flow of logic within your system in a visual manner, enabling
you to both explore and validate your logic.
State chart diagram Whiteboard State chart diagrams depict the various states, and the transitions between those
states, that an entity exhibits. During analysis modeling state chart diagrams are
used to explore the lifecycle of an entity that exhibits complex behavior.
System use case
Paper
A use case is a sequence of actions that provide a measurable value to an actor. A
system use case includes high-level implementation decisions in it. For example, a
system use case will refer to specific user interface components such as screens,
HTML pages, or reports. System use cases will also reflect fundamental
architectural decisions, such as the use of ATMs versus cell phones to access your
bank account.
UI prototype
Whiteboard A user interface (UI) prototype models the user interface of your system. As a part
of analysis modeling it enables you to explore the problem space that your system
addresses in a manner that your project stakeholders understand. Remember, the
user interface is the system to most people.
Usage scenario
Index card A usage scenario is exactly what its name indicates the description of a potential
way that your system is used.
Use case diagram
Whiteboard The use-case diagram depicts a collection of use cases, actors, their associations,
and optionally a system boundary box. When analysis modeling a use case diagram
can be used to depict the business functionality, at a high-level, that your system
will support. It can also be used to depict the scope of the various releases of your
system via the use of color or system boundary boxes.

5. Conclusion
The nature of analysis has changed. Several decades ago analysis was seen as a transformational process within a serial
project lifecycle. With the rising popularity of object-orientation in the 1980s and 1990s analysis was soon seen as part of an
iterative and incremental process, and in the new millennia the nature of analysis is transforming once again. Today analysis
is better envisioned as a highly collaborative, iterative, and incremental endeavor involving both developers and stakeholders.
The evolution of the analysis process necessitates an evolution in the way that business system analysts (BSAs) work, and in
many situations this role arguably disappears in favor of developers who are Generalized Specialists.

6. Acknowledgements
Id like to acknowledge the input on the Agile Modeling mailing list (www.agilemodeling.com/feedback.htm) of the following
people: James Bielak, Adam Geras, Ron Jeffries, Kent J. McDonald, Les Munday, Paul Oldfield, Stephen Palmer, Tom Pardee,
Dave Rooney, Gabriel Tanase, and Paul Tiseo.

7. References and Suggested Reading

See the references page.