Skip to content
  • Services
    Our Approach
    Personalized, in-depth technical guidance on a global scale that helps organizations achieve their digital transformation goals.
    Learn more
    • Our Approach
    • Artificial Intelligence
    • Development
    • Design
    • Digital Experience Platform
    • Data & Analytics
    • Cloud & DevOps
    • Security & Compliance
    • Support
  • Industries
    Our Work
    Through our expertise in strategy, design, and engineering, we help clients deliver digital transformation at scale.
    Learn more
    • Our Work
    • Healthcare
    • Financial Services
    • Manufacturing
    • Agriculture
    • Education
  • About
    About us
    For over 20 years, we’ve partnered with companies of all sizes and industries to solve their most complex business problems.
    Learn more
    • About us
    • Locations
    • Events
    • News
  • Careers
    Join our Team
    Take your career to the next level. We offer exciting opportunities across every stage of the software development life cycle.
    Learn more
    • Join our Team
    • Open Positions
    • Application Process
    • Benefits
    • Learning & Development
  • Insights
    Our Insights
    Read our latest blogs, watch our recent videos, and browse our library of e-books — all full of insights from our experts.
    Learn more
    • Our Insights
    • Blogs
    • Videos
    • Downloads
  • Contact
Menu
July 18, 2023

Increasing the Agility of Agile with Business Analysts

How do BAs drive agility? By adapting to change, facilitating communication, and creating new ways of working.

David Tomov-Strock

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.

Tags
  • Agile Software Process
  • Development
  • Strategy
  • Digital Transformation
Share
  • Share on Facebook
  • Share on LinkedIn

Agile Software Development

Why businesses need remote Agile teams & questions to ask before starting.
Download
Share
  • Share on Facebook
  • Share on LinkedIn
Sign up for our monthly newsletter.
Sign up for our monthly newsletter.

Read what's next.

Blog

Secure Your Future with Post-quantum Cryptography

Blog

Enhancing Food Processing with Digital Twins

  • LinkedIn
  • Instagram
  • Facebook
United States
MentorMate1350 Lagoon Ave, Suite 800
Minneapolis
, MN 55408

+1 612 823 4000
Bulgaria
67 Prof. Tsvetan Lazarov Blvd.
Sofia 1592, Bulgaria,
+359 2 862 2632
Sweden
Gustav III:s Boulevard 130
P.O.Box 3069
SE-16903 Solna

+46 10 481 00 00
Paraguay
Carlos M. Gimenez 4855
Asunción, Paraguay

+595 21 327 9463

Copyright © 2025 MentorMate, LLC

  • Cookies
  • Privacy
  • Terms
  • Continuity Policy
This site is registered on wpml.org as a development site. Switch to a production site key to remove this banner.