In this KnowledgeKnugget™ you will learn how Agile software development approaches such as SCRUM and SCRUM/XP hybrids affect business analysis activities.

The Role of the Business Analyst in an Agile SDM

Agile is an approach to delivering information technology (IT) solutions that focuses on changing business needs and technologies. The founding group published its premise and promise on the web in 2001 as “The Agile Manifesto”, declaring (amongst other things):

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development.
• Business people and developers must work together DAILY throughout the project.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Simplicity — the art of maximizing the amount of work not done — is essential.

This means that the person wearing the business analysis hat on an Agile project (whom we call THE BA, whether or not that individual has that job title) does business analysis strictly on an as-needed basis. However, as with every other methodology, some degree of up-front definition of business vision, goals, objectives, and high-level stakeholder requirements is essential.

Of all available methodologies, Agile is the approach most receptive to change. Nothing is permanent until the project has delivered a solution that is “sufficient to the needs of the users”. There are several Agile methodologies available. Currently, the most well-known are Scrum, Lean, Kanban, eXtreme Programming (XP), Crystal, Dynamic Systems Development Method (DSDM), and Feature-Driven Development (FDD). As of 2012, about 74% of Agile projects follow the Scrum approach or are Scrum/XP hybrids.

The SCRUM approach divides software development into small chunks known as “Sprints”, each of which deliver a working piece of software (aka: incremental functionality). An “Iteration” is a series of Sprints which taken together deliver a software component that provides business value to the customer.

One distinguishing characteristic of all Agile methodologies is the lack of distinction between phases such as Analysis, Design, Coding, and Testing. All of these activities occur iteratively within the Sprint. In the Scrum and Scrum/XP hybrids, the major mode for expressing requirements is the User Story. A User Story describes what the system needs to do for a specific user role and why the user needs it. The Agile team creates a set of tasks for each User Story to be able to estimate and coordinate individual work.

In Agile, as in every other methodology, a project starts with some form of a vision. The vision can be in someone’s head (in which case someone needs to formulate and communicate it to the team) or any other form of representation. Formal business goals and objectives or an official “Vision Statement” are common forms.

Regardless how your organization expresses it, it has to define:

• What business problem(s) the project will solve
• What the business goals and objectives are
• What features and benefits will be provided
• Who will be the recipient of the solution

It may also include statements about performance, reliability, platforms, standards, applications, etc.

One of the first steps in Agile development is to create an initial “Backlog”, commonly called a “Product Backlog”, “Kanban board”, “Feature Set”, or something similar depending on the specific methodology. The Product Owner is ultimately responsible for maintaining the Backlog which is initially seeded from an analysis of the vision. Due to the nature of this work, THE BA is often tasked with it.

Depending on the maturity of the Agile team, the Backlog can contain anything from business goals and objectives, Business Requirements, “Themes”, “Features”, “Epics”, etc. to Stakeholder Requirements at any level of detail (commonly in User Story format). The Agile team uses the Backlog to plan Iterations and Sprints. Pinpointing the exact level of detail is not necessary early in the project because THE BA (again, whoever is wearing the Business Analysis hat) will do that in more detail during the Iteration or Sprint planning sessions on an as-needed basis.

The Backlog lives. THE BA adds new and changing User Stories and/or Work Items throughout the project. The Agile Team prioritizes the Backlog often to ensure that they are working on what are at that time the highest priorities for the project. Requirements within a Sprint are often quite informal and undocumented. The most formal requirements in Scrum/XP approaches are User Stories written on index cards or maintained in an electronic system. Notes scribbled on a cocktail napkin (which THE BA can scan as documentation, if necessary) are also an acceptable form.

Your involvement as THE BA will depend on the specific Agile methodology chosen. With Scrum and Scrum/XP hybrids, typical Agile Teams consist of the specific roles:

• Product Owner or customer representative (who is or has access to THE BA)
• a Scrum/Agile Master
• Developers
• Testers

It is interesting to note that each individual’s role on an Agile project is fluid and can change as the need changes. This mandates a high degree of flexibility and a broad set of skills of each team member, each of whom may become THE BA at different times in the project. To be successful, THE BA needs a versatile set of tools for eliciting requirements on the fly.

Ideally, the entire Agile team is physically co-located to satisfy the Agile premise regarding face-to-face communication. Geographically dispersed teams can use virtual presence to come as close as possible to physical co-location.

Although the techniques for specifying (aka decomposing or flushing out) Stakeholder Requirements in Agile are much the same as in any other development approach, the timing and level of detail are VERY different. It is a true balancing act between making sure that the requirements are “good enough” to ensure that all stakeholders in a project are fully satisfied while avoiding any unnecessary business analysis activities or techniques.

In Agile, THE BA facilitates the process of defining, analyzing, comprehending, organizing, optimizing, testing, and integrating the requirements for a given Sprint. Ultimately, the entire team is responsible for deciding whether decomposed User Stories are sufficient or the team requires techniques that are more elaborate. The team may have to create Activity Diagrams, process models, data models, State Diagrams, or other models to communicate the intent of the requirements and not just the words.

Once the developers have built and tested a User Story, it has to undergo Acceptance Testing. In many organizations, this is the responsibility of THE BA. In some Agile teams, THE BA also creates and executes test cases and scripts for the developers as part of Unit Testing. THE BA may also be responsible for generating testing reports for the developers.

As of 2012, the Agile approach is rapidly becoming the methodology of choice for IT projects. Proven successes on projects of suitable size is a major contributing factor. According to industry studies published in 2011, Agile projects are more than twice as likely to succeed as compared with those using a structured or spiral approach. Until recently, the team-driven nature of the Agile approach has constrained the size of projects for which it is likely to succeed. However, as organizations and the IT industry gain more experience with Agile, they are constantly pushing the size envelope.

At the current time, the Agile team approach is best suited for dealing with the complexity and rate of change inherent in modern information technology development.