Agile methodologies have introduced a big shift in how teams approach business analysis activities. In this article I share my thoughts on business analysis when working agile.

SHIFT IN WAY OF WORKING

The shift in approaching and organizing business analysis activities by agile teams is caused mainly by two contributing factors:
• Absence of a business analyst role. The role of a business analyst, that we know from traditional development methods has disappeared. Business analysis activities are now performed by the product owner in close cooperation with the development team. The SCRUM guide states clearly that the “Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment”. The development team, consisting of T-shaped professionals, should possess the required business analysis skillset.
• Lack of the upfront analysis phase. The agile methodologies do not recognize the upfront analysis phase during which requirements elicitation and analysis take place prior to the development effort. This phase is not longer needed; the approach of specifying all requirements upfront and expecting they remain unchanged through the rest of the development has proven to be wrong. Stakeholders cannot predict what they require and cannot provide details in early phases of the project. Therefore projects detail requirements based on their business value and importance to the business in a “just in time” manner.

ENVISIONING AND DISCOVERY

Every initiative requires a direction to lean on. This direction is reflected in a clear problem statement, that specifies what the team needs to address. It is accompanied by a vision describing what the team aims to achieve; as well as goals, objectives, and essential epics. These elements are required to give the team guidance and provide them with understanding of what it is they are asked to contribute to. When the team understands what the organization wants to achieve, why and for whom, then it is able to find the best possible ways to solve the given problem and achieve the vision. On the other side, the same elements give clarity to the organization on what the team will spend their time and money on.

Defining the problem statement, developing a vision and identifying stakeholders with their goals and objectives is all business analysis work. The focus of this work is outcome related. This business analysis activities are performed by a product owner, stakeholders and development team. It covers the breadth of what is required on a (relatively) high level of abstraction. Detailing requirements upfront is not necessary; it would be a waste. New insights discovered during development can easily impact the details, therefore the in-depth analysis takes place in “Just in Time” manner; in the last responsible moment.

Figure 1: Breadth of what’s required is discovered during the envisioning and adjusted after each iteration

The product owner (relying on input from business stakeholders) indicates the most valuable requirements. Agile business analysis efforts continue in each iteration to detail them first. In doing so, the items with most business value can be delivered early.
It would be a mistake to state that discovery is a one-off phase – it is not. After every iteration we gather learnings and feedback that might impact the direction of the initiative. We adjust the direction if required. This is a strength of the adaptive character of agile methods that embrace change in response to the fast-paced environment.

DELIVERY

During the iteration in-depth agile business analysis takes place to detail the work to be done. The agile team details user stories making them ready to play (ready to be implemented). This means they work collaboratively with stakeholders to define acceptance criteria, decompose epics/features into user stories, add details to the user stories like models and sketches, clarify details, identify risks and dependencies, check the relevance of backlog items to achieving the goals, remove stories that are not relevant, estimate and prioritize. The list of activities they take up is long and all these activities relate to business analysis. The team decides what detailing is required, what models are produced and which techniques are applied. A collection of conditions that an item must comply with before being considered for implementation is called a definition of ready. The team defines the definition of ready in an empirical way, trying what level of detailing works and what doesn’t.

Figure 2: During each iteration detailed, in-depth analysis takes place

Learnings and feedback after each iteration provide a valuable trigger for discovery of new requirements. New insights (may) lead to changes in direction and scope, too.

TIMING OF BUSINESS ANALYSIS

The trick with in-depth agile business analysis lies in its timing. The story needs to be analysed before it is selected for implementation. On average, the team requires two to three iterations to create sufficient shared understanding that increases the chances of completing the story within an iteration. Dean Leffingwell in his book “Agile Software Requirements” has already proven this with research (see figure 3).

Figure 3: Probability of story completion as a function of story maturity

The team that spends time analysing stories upfront of an iteration ensures that these stories are more likely to be completed once they are selected for implementation. The analysis activities prove to have an added-value again.
A consideration for analysing user stories is to prevent refinement of too many stories upfront and therefore generating inventory waste. On average the top of the product backlog should contain two to three iterations of “ready to be implemented” stories; just enough to ensure that if the team has spare capacity, they can pull the stories to the iteration.

AGILE BUSINESS ANALYSIS = BREADTH + DEPTH

We can conclude that business analysis takes place in agile development. It has two dimensions –  one dimension relates to breadth of requirements. It frames the initiative by defining a problem statement, vision, goals, objectives and epics. It is where the expectations are defined without specifying the details. Details will be discovered at the right time. The second dimension relates to detailing requirements in the “just in time” manner through in-depth analysis that takes place during the iteration. The learnings and feedback from the in-depth analysis (may) impact the breadth; goals and objectives can be adjusted to reflect new insights and new epics may see the daylight. When we put these two dimensions together the following overview emerges:

Figure 4: Framework for business analysis in agile context

Iterative agile business analysis activities tackle breadth and depth of requirements. Business analysis in agile is not longer a one-off project phase. Instead, the agile team continuously engages with stakeholders to discover and detail work to be done. The timely character of analysis activities enables the agile team to spend their time effectively and efficiently on working out the most important, valuable requirements first to the right level of detail in line with the spirit of agile principles and values.