The Agile Business Analyst: 4 Crucial Strategies for Success

Many business analysts feel like their role is not needed in agile. We hear that agile teams don’t want “requirements” and so we assume they don’t want business analysts!

Nothing could be further from the truth. Here’s exactly why agile teams need business analysts.

 

For those who like to read instead of watch, here’s the full text of the video:

Many business analysts feel like their role is not needed in agile. We hear that agile teams, they don’t want requirements. Then we assume that they don’t want us as business analysts. Nothing could be further from the truth.

I’m Laura Brandenburg. I’m the creator of Bridging the Gap. Today, we’re going to talk about why business analysts are absolutely essential to agile teams.

Recently, one of our community members commented that in his early meetings with agile practitioners, he felt like something was off, something was missing. He wasn’t quite sure what it was. After going through our free training, he discovered it was the business analysis part of the process.

Where did those requirements come from for those users come from for those user stories?  What was that working software supposed to do?  That information comes from us, the business analysts.

One of my mantras is that on every successful project, you’ll find a business analyst. That’s true, even if they don’t have the title of Business Analyst.

Agile, as wonderful as it is, it’s not a business analysis process. It’s a way of developing and delivering valuable working software to the business. Agile teams, they need business analysts.

  • They need us to discover what the business users need and want and determine what changes will have the most value to the business, so we can effectively use agile software development practices to deliver it with maximum efficiency.
  • They need us to collaborate with business users and sponsors across the organization, and to gain alignment on what is wanted and needed and ensure that those items in the product backlog and those details in the user stories represent true value to the business.
  • They need us to take a holistic view of the product backlog and find all those inner related requirements and inter-dependencies and make sure that the pieces of working software delivered are, again, going to deliver value in the context of that end-to-end business process.
  • On that note, they need us to discover and analyze what those business processes are and help the business users implement the changes necessary to fully leverage that new software. That is supposed to make their jobs easier.
  • Last, but not least, they need us to keep the backlog well organized. To keep it groomed and prioritized, and add those estimates and filter through it, remove things, and add things so that the team can easily see what needs to be done in the next sprint, and the sprint after that.

Agile practices and business analysis actually deliver tremendous value to organizations when they are leveraged effectively together. Let’s stop questioning why we need business analysts in agile, and let’s start looking at how we can all work together to achieve the most possible value for our organizations. Things will be so much easier when we’re all working together as a team.

I do have some more resources for you on how to be an agile business analyst. There should be a link to this video or go to bridgingthegap.com/agile-business-analyst. I’ve laid out exactly how to apply the business analysis process we teach at Bridging the Gap, and in agile software development environments. Be sure to check that out.

I challenge you. What will do to be a better partner to your agile team today?  How will you help your organization be more effective?  How can you leverage the combination of agile practices and business analysis to deliver even more value more quickly to your business community?

Leave me a comment below. I’d love to hear about your success.

Again, I’m Laura Brandenburg from Bridging the Gap. Thanks for listening.

The Agile Business Analyst: 4 Crucial Strategies for Success

To follow-up from this video, let’s look at 4 crucial strategies for applying the business analysis process in an agile environment.

Agile Business Analyst Strategy #1 – Resist the Temptation to Skip Steps 1-3

Most agile practices make certain assumptions about what information the business stakeholders can provide and how quickly they can make decisions. These assumptions are valid inside steps 5-7 of the business analysis process. But steps 1-3 (Getting Oriented, Discovering the Primary Business Objectives, and Defining Scope) are still important.

As an agile business analyst, these decisions you help stakeholders make in these steps provide the foundation you need to effectively and iteratively deliver the requirements in step 5.

  • The current capabilities assessment completed in step 1 will help you and your team discover simple, quick wins that can add value quickly.
  • The business objectives discovered in step 2 will help your team prioritize the product backlog to put the highest value items first.
  • The scope decisions made in step 3 will help your team stay on track and make meaningful adjustments to expectations.

Most often, these steps will start before the “agile” part of the project and it’s prudent to make time for them even as an agile business analyst.

(By the way, we cover each of the 8 steps of the business analysis process in our BA Essentials Master Class.)

Agile Business Strategy #2 – Create an Agile Business Analysis Plan (Step 4)

When it comes to step 4 – creating your business analysis plan – this is where it’s important for the agile business analyst to integrate the business analysis process into your organization’s version of agile.

Here are some specific questions you’ll want to answer as you work through your planning:

  • How long are sprints scheduled for?
  • What happens inside a sprint? Is there time for elicitation and requirements work or is the sprint all about developing and testing?
  • What is the desired outcome of a sprint? Production-ready code is the typical standard but ready-to-test code is also a common deliverable in partially agile teams.
  • How does the project team decide what to work on inside a sprint?
  • What state does a product backlog need to be in before a sprint?
  • What state do the user stories need to be in before a sprint?
  • Who is responsible for the product backlog and user stories? While these are natural responsibilities for an agile business analyst to take on, your project team may have a different way of doing things.
  • What requirements work will happen inside the sprint?

Essentially, you want to figure out exactly how to fit your detailed functional requirements work into the agile process of your software development team.

Agile Business Strategy #3 – Plan for Multiple Iterations of the Detailed Requirements and Team Support (Steps 5-7)

Fundamentally, agile is an iterative development process. On the best agile teams I’ve been a part of, we developed a pattern of requirements, design, development, and testing that flows continuously so that everyone is always working on something meaningful. And this means the agile business analyst might be working on requirements that are developed and tested next week, or even tomorrow.

In the BA Essentials Master Class, we discuss specific ways to develop the detailed requirements iteratively in step 5. And it is important here to be sure you are eliciting, analyzing, and finalizing the requirements in an iterative, continuous fashion, so your product team has a steady stream of work for each sprint.

What’s more, while you are finishing requirements for the next sprint, you are also supporting the technology team during the current sprint (step 6). And you might also be supporting the business in implementing the changes from the previous sprint (step 7).

So steps 5-7 all happen, but they happen at the sprint level instead of at the project level, which means that in reality, you are working on all 3 steps at once.

In my experience, this is the biggest shift for us to get used to as agile business analysts, because this pattern of work requires us to manage our time extremely well and make sure we are working on only the most important tasks with each step. There is no time here for endlessly tweaking models or finessing the phrasing of requirements. Instead, we should be collaborating, reviewing, and getting all of our work “good enough” to take the next step.

Agile Business Analyst Strategy #4 – Regularly Assess Value in Step 8

Step 8 in the business analysis process involves assessing the value created by the solution. And here is where we as business analysts can start to fall in love with agile methodologies. In a more traditional, waterfall environment we might wait months or years to see our requirements implemented and the value intended by those requirements realized.

In an agile environment where production-ready code is delivered regularly, we might see slices of value realized within weeks. And that means we can also be assessing the value of those changes earlier, and communicating about the value already delivered by the project team before the team is even done with the project.

This kind of celebration and communication can create a lot of positive momentum inside our project teams and across our organizations. What’s more, as we see the initial changes deployed, we’ll often learn even more about what the next set of valuable functionality is, generating new ideas for new projects and backlog items, which will require regularly grooming the product backlog. Instead of staying stuck on what was originally in scope, it is important to leverage this learning and make adjustments.

An Agile Business Analyst is Still a Business Analyst

Although we might apply the business analysis process differently in agile, it’s just as important as ever to be a tried-and-true business analyst in an agile environment. In fact, if we try to skip over steps just because we are doing agile, we are likely to face more challenges inside our projects.

If you are a business analyst on an agile team, consider how you demonstrate leadership within your own domain of business analysis by applying these crucial strategies to increase your effectiveness.

Learn More About the Business Analysis Process

To learn more about the 8 steps business analysis process, sign up to receive this recorded webinar training – 8 Steps to Being an Effective Business Analyst. (It’s complimentary.)

You’ll learn about the 8-step business analysis process that you can apply whether you are in an agile environment or a traditional one, whether you are purchasing off-the-shelf software or building custom code, whether you are responsible for a multi-million dollar project or a one-week project.

Click here to register for the complimentary training

3 thoughts on “The Agile Business Analyst: 4 Crucial Strategies for Success”

  1. Pingback: Cómo escribir historias de usuario – krakken

Leave a Comment

Your email address will not be published. Required fields are marked *

Sign up for weekly updates and access to the FREE Quick Start to Success workshop:

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

Laura Brandenburg
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.

Scroll to Top