Increasing the Agility of Agile with Business Analysts

Let’s address the elephant in the room: business analysts are often perceived as rigid creatures, bound by rules, diagrams, and meticulous documentation. And to some extent, that perception holds true. We take pride in our structured approach, ensuring that no detail goes unnoticed and every requirement is captured accurately. 

But here’s the secret sauce: business analysts are also the drivers of change, the catalysts that push teams to achieve unprecedented levels of agility.

So how exactly do business analysts increase the agility of teams?

Adapting to change

Think about it. Agile projects thrive on adaptability, continuous improvement, and seamless collaboration. And even though change is hard, we, as business analysts embrace these principles with open arms. 

Our innate desire to deliver excellence fuels our relentless pursuit of continuous improvement. We understand that what worked in one project may not work in another. Our adaptability enables us to tailor our approach to the unique needs of each team and client. We flex and mold our methodologies, the way we write user stories, and meeting strategies to ensure maximum efficiency and productivity. By meeting the needs of others, we empower them to perform at their best. We believe in adapting our work to the team and the client, which means how we write user stories or create diagrams may change from project to project. We will even adapt the way we run meetings or conduct requirements gathering. We are accustomed to meeting the needs of others so that they can get their work done more efficiently.

Therefore, it’s not a big leap for us to adapt to process changes during a project. One of the ways we have been able to succeed in this is through constant and consistent knowledge sharing and upskilling. On one of our projects, when the client asked us to start including behavior-driven design test cases in our user stories, we were able to take a peek at the resources already available and find that we already had an informational article ready with the knowledge we needed to implement this request right away.

Facilitating communication

When looking at why projects fail, poor communication is always listed as one of the reasons. The other reasons, while not caused by communication failures, can often be resolved or mitigated with good communication. Project managers are usually the individuals responsible for ensuring the overall success of a project, but business analysts play a key role here.

Business analysts possess a unique vantage point — they’re on the ground with the rest of the team, they get to see the big picture just like the project managers do, and they have such a close relationship with the product owners that they often know what they’ll say before the product owners do. This position allows us to see issues from multiple perspectives and to analyze how a particular decision will affect different people.

So when we hear about a change coming from a product owner, we can get in front of that and prepare the team for the upcoming transformation ahead of time. Or when the team’s morale dips, we can go straight to the project manager to brainstorm ways to get us out of the funk.

Creating new ways of working

When we, as project teams, say that we work with Scrum or LeSS or any other methodology, we mean that we work within a framework. And those frameworks, by their nature, give us some flexibility to adapt them to ensure that we deliver the best work possible to our clients.

We’ve already discussed how business analysts are adaptable and communicative. They are also innovative. For example, one project started with process flow diagrams as a go-to artifact. Still, we quickly realized that we were missing a key piece of information in both the diagrams and our documentation that could be easily understood by all involved. 

How do the attributes of a specific object change as a user moves through the flow? We came up with a process flow diagram using BPMN combined with objects using UML, which could be considered a new type of user/object relationship flow diagram. The result was that the product owner was able to easily visualize and verify the behavior of the application before development had even started on these features. At the same time, the software engineers knew exactly what to develop and the quality engineers knew exactly what to test.

On another project, we were struck by the limitations our story templates had. Most everyone knows about user stories. Also in the business analysis toolkit are job stories and technical stories. User stories are the default because they provide so much in just one sentence:

• A user to focus on
• An action that needs to be completed
• A value for the user

Job stories switch up the format a bit and are used when there doesn’t need to be a differentiation between users, but they still detail the action and the value. Technical stories, meanwhile, are mainly used for back-end tasks where a user isn’t involved. Instead, they describe an expected outcome.

Working with the client on this project, however, we learned that they were unhappy with stories with no clear value, which meant that they were unhappy with the technical stories. It didn’t make sense to turn the technical stories into faux user stories (i.e. “As a database, I want a new table added so that I can store different information.”) nor did it make sense to spend time on the mental gymnastics required to turn technical stories into true user stories.

The solution ended up being quite simple. All we had to do was take the best of user stories and combine them with the best of technical stories. This new story type consists of the following:

• A clear outcome
• A business value

Therefore, this new type of story might look something like this:

• Add an address table to the database so that the company has easy access to addresses for mass mailings.

We decided to call this a business story because we are declaring right in the story the business value of a technical change. The other positive outcome is that we can now ensure that we are delivering value to our client with every story we develop.

Final thoughts

Business analysts are already doing all of this and more on their projects with various clients, thus easing the work for the teams and helping those teams produce better products for their clients. Recognizing these contributions, however, is key to ensuring that we set ourselves on a path toward continuous improvement by allowing ourselves to become even more agile than we already are.