3 horizons of agile analysis

We live in a time when being adaptive and nimble is no longer a matter of choice for businesses — it is a matter of survival.

There are many reasons for the above, including the fact that we live in an extremely interconnected world; a world like we have never seen before.

A natural or social phenomenon happening in one part of the world can affect organisations in another in an unpredictable manner. In 2011, a monsoon season in Indochina saw a record flood event across several countries. Not only was it a local disaster affecting the lives of millions, it also disrupted a worldwide supply-chain in the technology sector causing billion-dollar losses and severe parts shortages for the rest of the world [1].

Such changes cannot be predicted. In this world, there are just too many variables in the equation to make reliable forecasts. It becomes hard for businesses to commit to long-lasting business plans, and for software teams to spec out and deliver multi-year projects. By the time the project finishes, the state of the world will be completely new and the product which seemed to be needed back then may become completely useless.

This is an issue that business agility is trying to solve. An agile business assumes the world will always be full of unexpected surprises. It makes the fact that changes happen a new reality. It learns, and it adapts.

In turn, this changes the expectations from different roles in organisations — business analysis included.

Let’s explore how a business analysis practice helps an organisation embrace agility. It does so on three horizons [2].

Strategic horizon

In a situation of uncertainty, one of the main strategic challenges is to make decisions based on up-to-date data. The focus of business analysis efforts on the strategic horizon is on informing decisions regarding an organisation’s business goals, and figuring out what is the best allocation of available (limited) resources to support the selected strategy.

This means that a business analyst should be equipped to help the business decide which initiatives out of the variety of potential options to invest in.

Practically, this means focusing on understanding business goals, breaking them down into objectives and measurable criteria that can be used as selection criteria for the initiatives. This effectively creates a framework designed to prioritise initiatives and build a strategic roadmap out of them.

At the same time, proper analysis will constantly evaluate emerging opportunities against the criteria defined, and will focus on enabling quick and effective decision making via providing relevant and up-to-date information and reducing complexity.

There are a few tips that may help with this task.

Make sure you have established a shared vision and value proposition, these will help you define the goals and break them down. Understand who your customers are and what their journey looks like [3]. Consider mapping the steps of how the business delivers value to your customers (value stream maps) and aligning them to the customer journeys. Finally, create a prioritisation framework and visualise the backlog of initiatives. You can use a kanban board or any other technique to do this.

It is not an easy thing to help businesses overcome strategic challenges. Even though there are common techniques that can help with the task, one will often have to come up with a very tailored approach based on the specifics of the business and the environment.

Initiative horizon

Once the priority initiatives are identified on the strategic horizon, it is high time to shape each individual initiative and prepare it for delivery. The business analysis effort for each one should be focused on identifying potential solution options that meet the business goals while being compliant with any identified constraints. A business analyst will then recommend the options to consider and scope them in terms of solution components that will need to be delivered.

That’s the theory. What might this look like in practice?

Let’s say, for example, that you have a business goal to enable self-service for customers. One of the potential initiatives may be to surface some of the internal corporate knowledge bases for end users. That initiative may have a preferred solution option to build a chat bot to support common customer requests. And the solution components can be scoped around:

• the changes on the website to enable the chat bot

• the changes in the mobile app to enable the chat bot

• the changes to the knowledge base to support the chat bot

• and the bot’s internal logic

This is when user stories [4] and user story maps come into play as tools to capture and share the scope. You could also employ complementary scoping techniques such as storyboarding at this level.

For each solution component, it is important to keep in mind how exactly it is going to support the goal. Often it manifests itself via addressing a specific need of a particular customer group, so understanding who your users are and what needs they have becomes crucial here. This understanding will help you make prioritisation decisions. You need a way to determine which features of a solution component are absolutely necessary for the success of the project, which can be simplified or deferred, and which can be excluded from the scope altogether.

Timely feedback is one of the key tools in scoping initiatives. Getting the product in front of the real users early on (even in the form of early sketches or prototypes) will help you further define the boundaries of the solution, validate hypotheses, and identify if particular design decisions are going to produce the anticipated outcome.

Delivery horizon

It is not enough to design and scope a solution — you have to build and deliver it to enjoy the benefits.

On the delivery horizon, a business analyst focuses on ensuring the delivery team has enough information to build and ship the product. This usually means the team has a prioritised and refined backlog of development-ready user stories that they can work off.

Business analysts are not self-contained in documenting the backlog though. The pivotal role a BA plays on the delivery horizon is in the ability to ensure the smooth delivery of expected value. A BA will collaborate with team members to ensure there is a shared understanding of the original need, that the order of delivery maximises the value and learnings, and that the means of assessing the quality of outcomes are established.

In the example above, a BA will not only create and maintain a backlog for building a chat bot. They will also define measures of success for the project, ensure the analytics are in place to capture those measures and decide whether the initiative is successful. Moreover, if any business changes are required to support the new solution (i.e. business process changes or training for staff members), it is also the BA’s job to identify those and ensure respective activities happen in time for the new solution to be deployed.

The majority of day-to-day effort during the delivery will go into:

• slicing and elaborating user stories in the backlog

• scoping meaningful product increments

• assessing risks and organisational readiness

• ensuring new learnings are reflected in the backlog

• ensuring the solution is continuously evaluated against original needs — whether the scoped solution is still the best option to address those needs and whether the needs are still relevant

The three horizons are interconnected

Although we do separate the horizons, it is important to know that we are not talking about creating silos here.

It is not about hiring three people to do three separate jobs.

Nor it is about addressing the horizons in different stages of the software development lifecycle (SDLC).

It is more about the flexibility of mind to switch context and think on a different planning horizon when the situation demands. Moreover, you will constantly find yourself coming back and forth between the horizons, as they feed the information into each other.

It is pretty obvious how the strategy informs initiatives, and how the scope of an initiative informs the delivery of it.

But it is equally important to maintain the feedback loop. When building and operationalising solutions, you see which decisions work and which do not. You also see how the expectations of the customers change or the market situation evolves. All of these affect the priority and scope of your initiatives. As those change, so does the need for resources and the expected ROI of the initiatives, which in turn affects the strategic decisions to go ahead with certain projects.

Those processes form a continuous loop in organisations, and it is business analysis that helps build systems around them to increase organisational efficiency in making decisions and executing them at the project level.

A business analyst’s role in the three horizons

To recap, a BAs role on the three horizons of analysis is:

1. Strategic: help businesses make strategic decisions in an agile context and select the initiatives to deliver;

2. Initiative: help the teams understand the real needs of their customers and scope projects accordingly;

3. Delivery: help the teams deliver projects in an agile setting.

When done correctly, it brings the following benefits to the business [2]:

• Provides a link between the organisation’s strategy and the initiatives resourced to meet the goals of the strategy;

• Discovers, interprets, and communicates information in order to increase understanding and clarity on where value can be created;

• Clarifies for whom value is created, who can contribute to the creation of value, and who else might be impacted, and;

• Helps stakeholders make decisions.

Being a business analyst in an ever-changing world is an exciting place to be.

References

1. https://en.wikipedia.org/wiki/2011_Southeast_Asian_floods

2. Agile extension to BABOK(r) Guide

3. https://medium.com/analysts-corner/converting-experiences-into-actionable-backlogs-b4a699fdedd8

4. https://medium.com/serious-scrum/anatomy-of-a-user-story-c2e54a24eaf7