Business Analysts as Carriers of Value in the Organization

The power of analysis for business agility

In a world with fast-pacing businesses (or characterized by being VUCA — Volatile, Uncertain, Complex, Ambiguous), organizations need to be agile if they want to thrive. How can organizations structure themselves towards business agility? Professionals of (agile) Business Analysis have the potential to be carriers of the value that organizations deliver, from the team to the organization. Well-known analysis techniques are useful when applied with the right context and the right mindset.

Credits: GoodFon

A while ago there was a misconception of the (un)usefulness of business analysis in agile environments. This is because agile frameworks didn’t include any business analysts in their list of roles. It lead to the idea that BAs had no future in organizations. that couldn’t be farther from the truth. We will explain how BAs can be key drivers in an organization structuring itself for agility.

The focus should be on business outcomes. BAs have the power to influence the team in delivering features that provide the most value to the organization and that are key drivers to those business outcomes. Business analysis techniques are capable of gathering the data to support the decisions needed to achieve the outcomes.

The most common scenario is a BA working together with a delivery team focusing on a shared understanding of user stories and managing the backlog. Their work should encompass more and more analysis at the strategic level. This is how they can help organizations to achieve better business outcomes.

The agile horizons were Business Analysis work

The types of inputs that BAs can provide have different usage perspectives depending on the Agile Planning Horizons. They were originally defined in the Agile Extension of the BABoK®: Strategy, Initiative, and Delivery. The latter is the horizon where BAs work with the team with very fine-grained information in a very short-term span. As the work goes from the Delivery to the Initiative and then at the Strategy horizons, both the granularity of the information and the time span grows. The scope becomes wider.

We need to understand agility from these different viewpoints. Fabricio Laguna nicely describes these viewpoints with another concept called Flight Levels, from Austrian author Klaus Leopold in the book Rethinking Agile, Horizons and Flight levels are very similar metaphors, explained here (in Portuguese).

• The Strategy Horizon: refers to the decisions that impact the entire organization. Decisions made at the Strategy Horizon identify the products, services, and initiatives to which the organization allocates resources. The BA’s role when working in this horizon include identifying short-term goals, initiatives, and risks that align with organizational strategy, and articulating the problems that must be understood to make strategic decisions
• The Initiative Horizon: refers to decisions that impact a particular goal, initiative, or team. The BA’s role is to inform decisions about solution options, features, priorities, and lifespan. Those decisions will likely be made by a Product Owner or Product Manager.
• The Delivery Horizon: refers to decisions made about the delivery of the solution. The BA’s role includes working with the delivery team to understand how to best break down work, how to deliver and test the value the team is creating, and how to learn from the work the team is doing.

Between each horizon, there are upstream and downstream feedback loops, which means that the outcomes within the three horizons are in constant movement.

Are BAs fitting in all agile horizons?

Of course that one BA won’t be able to support accross all three horizons. Unless we are talking in a very small and young organization, IMO. But it’s very common to see BAs working within two horizons. At very large organizations, a BA might be working at a single horizon.

Keith Ellis, Chief Growth and Engagement Officer at IIBA, conducted a virtual workshop at the eXperience Agile 2021 Conference, about this same topic this article is addressing. During the presentation, he did a quick survey with the audience. The BAs that were present worked mainly at the Delivery or Initiative horizons, or both. No one from the audience was working at the strategic level in the organization. But BAs have a lot of potential for supporting decisions at the strategic level. A bit below I will present how can they do that.

I was fortunate to make a presentation to the agile community in my company, Natixis, about this topic. I conducted the very same survey. There were a few attendees that work at the Strategy horizon. But again the majority was working at the Delivery, the Initiative, or the Delivery + Initiative.

But we need to understand that the alignment towards business agility is only possible when Strategy, Initiative and Delivery, and feedback loops between them, are fully supporting the decisions between each one. This means that business analysis supports decisions at all three horizons.

There are business analysis techniques used for each horizon, to help gather the data for those decisions. Some of those techniques are now presented. Please note that the ones in this article are kind of personal favorites. For a complete list of the techniques, please consult the Agile Extension of the BABoK®.

The analysis techniques to be used in the three horizons

BA at Delivery

In summary, BAs will work closelly with the team so that the work that is being delivered has the highest value. BAs will work for:

1. Ensuring that User Stories are Ready for Implementation
2. Maintaining the Backlog
3. Supporting Successful Delivery
4. Ensuring Learning Happens in the Agile Context

Some techniques to apply in daily work with the team include:

1. Story Slicing — User Stories, or Job Stories, need to be defined according to INVEST criteria. The goal is to ensure they are in a proper state for being included in an iteration, or if they meet the Definition of Ready. This is how BAs Ensure Stories are Ready for Implementation. Slicing is vertical (i.e., including all technical layers of the requirement) and not horizontal (separate the different layers, e.g., front-end, back-end, API, etc.)
2. Prioritization — User Stories, or Job Stories, in a backlog, are constantly analyzed for their business value, depending on how they impact a business outcome. BAs pass the message of the Product Owner’s priorities to the Team, by reviewing the priority order of each backlog item. It’s almost all the work BAs perform during an iteration for Maintaining the Backlog. This assures that the team is working on the most valuable items.
3. Gherkin syntax (from Behavior-driven Development — BDD) — it is a form of stating requirements. It is extremely helpful in passing the business outcomes to the team, by using examples in a “Given (the context) / When (the event or scenario) / Then (the outcome)”. It allows creating clear, meaningful acceptance criteria. BAs use these criteria for Supporting Successful Delivery.
4. Retrospectives — it’s a widely used form of introspection of how the teams conduct their process and their efficiency. BAs may make use of facilitation skills to mediate this event. If not in facilitation, BAs may use process analysis to enrich discussions. At the end of the day, their goal is to Ensure Learning Happens in the Agile Context.

BA at the Initiative

In summary, BAs will work on modeling and analyzing data to support solution decisions for a given initiative. These decisions are likely to be made by a product team (e.g., Product Owners, Product Managers). At this horizon, the information will have granularity at the level of features and not of Stories. BAs will work for:

1. Size of items
2. Identifying Solution Options
3. Recommending Solution Options
4. Identifying Solution Components
5. Prioritizing Solution Components
6. Determining if the Need is Satisfied
7. Ongoing Assessment of the Viability of the Solution

Some techniques to apply in solution work with the product team include:

1. Product Backlog — it’s the main form of communication of what is demanded by the product team to the team that will deliver. BAs collaborate with team members, stakeholders, and customers to clarify the need and identify additional detail. This can include reviewing priorities with stakeholders and moving or removing items as necessary. Composing the backlog will require work of Size of items, but also Identifying Solution Options (typically the features that will be sliced for Stories afterwards) and Recommending Solution Options according to the strategy for the Minimal Viable Product (MVP), or any kind of release. At the end of the iterations from the Delivery horizon, feedbacks will be analyzed for Determining if the Need is Satisfied and Ongoing Assessment of the Viability of the Solution, resulting in possible changes to the priorities.
2. Story Mapping — the features from Identifying Solution Options (typically the features that will be sliced for Stories afterward) and Recommending Solution Options are decomposed for Stories and components that are needed for modeling a user journey. BAs collaborate with product team and team members for a shared understanding of the sequencing of features but also to uncover the components to build for each feature. It is at this stage that the discussions relate to Identifying Solution Components and Prioritizing Solution Components. It is also possible to slice the elements from the Story Mapping to MVP and other releases.
3. Product Roadmap — the same features used in Story Mapping are planned and placed on a board in order to be implemented according to the desired vision. BAs uncover the required path towards the vision and form the plan. The order of features from the roadmap is then reflected in the order of backlog items in the Product Backlog.

BA at the Strategy

In short, BAs work closely with the strategic teams in an organization. The focus is on determining the value of the different initiatives towards the organizational goals. BAs will:

1. Observe if there are changes to customer expectations, outsider environment and within the organization
2. Map the organizational goals to individual initiatives
3. Reducing Complexity by breaking down systems and ideas

Some techniques to apply in strategic work include:

1. Impact mapping — it’s transparent to everyone the ‘Why’, ‘Who’, ‘What’ and the ‘How’. It’s not by accident that the sequence of the mapping is the way it is. It follows the same sequence as the “Golden circle”, from Simon Sinek’s “Start With Why”. And the biggest tip as analyzing the outcome for that initiative is exactly because…it starts with the “Why”.
2. Value Stream Mapping — it’s a visual map of the way workflows in an organization. By breaking down the systems and gathering of data, the processes are analyzed in terms of which ones add, or don’t, value to towards the business goal. Then, BAs bring the discussion about the non-added value processes and if they make sense to continue or if they are waste that should be discarded.
3. Portfolio Kanban — the ongoing initiatives are mapped across a kanban board. Each row is an initiative and each column is a different phase. Also, the initiatives are ordered by their current priority towards the organizational goals. BAs gather the feedback from the Initiative horizon and bring discussion if the order of initiatives should remain. In addition, the gathered data also should respond if initiatives should stay ongoing, if they met the objective already and end, if they should be canceled or if there is an ongoing need that demands a new initiative.

And now?

Found anything interesting? Perhaps worth presenting in your own organization? But what can we do next?

I’ll tell you what I did in the presentation I made at Natixis. I asked the audience to gather in the (virtual) whiteboard and to put sticky notes with the actions that they felt they could perform inside the organization. Like “present the VSM so we can start using it”, or “Impact Mapping so we can use them to link our OKRs with the existing initiatives”. And to put them in a column referring to whom they would perform this action. For example, the action about VSM could be with the Business people, the Impact Mapping one with Business and Product Owners, or for example another action for using Gherkin with the Team.

Of course, setting these actions will be only the beginning of the journey. It’s probably a good idea to make follow-ups on these actions. And then setting up new actions. Business agility requires, not only at the team level, but rather the entire organization, to embrace agile ways of working. I can assure you, adopting techniques from the Agile Extension of the BABoK® across the three horizons will help decisions are being made properly fed by feedbacks, and will allow organizations to be aligned.