How does the Business Analyst (BA) role change on an Agile project?

How does my role as a BA change on an Agile project?

One of the most common questions I hear from Business Analysts (BAs) at our Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO) classes is:

“How does my role as a BA change on an Agile project?”

Or

“What do I document as a BA on a Scrum team? And how much?”

There’s certainly a lot of frustration out there because it’s not clear-cut, leaving BA’s confused and unsure of what they should be doing. So let’s look at some answers to these questions.

What we used to do…

So on a traditional Waterfall project it was straight forward. A BA’s role involves gathering requirements at the beginning of a project, producing relevant documentation which is then shared with downstream teams who will formulate a design, implement the solution, and eventually test the end result. In some cases, BA’s are also involved at the tail end of the project during User Acceptance Testing (UAT).

Now while this all makes logical sense, and does work at times, there are a number of challenges that may occur.

The ‘requirement’ challenges we’re trying to solve with Agile

Miscommunication

I like this quote by George Dinwiddie:

Remember, it’s not the documentation that needs to be in sync, but the people.

While documenting all our requirements upfront can give us a greater sense of control and certainty, there is a risk that the documentation (or at least parts of it) will be misinterpreted. What if our architects, programmers and/or testers misunderstand what has been written? 

Misinterpretations lead to incorrect assumptions, incorrect assumptions lead to mis-aligned expectations, and mis-aligned expectations lead to unhappy customers 🙁

It can be incredibly frustrating when we’ve painstakingly documented the requirements, only to have them misinterpreted (or worse, skimmed over or ignored!) at later stages, and what has been produced at the end of our waterfall sequence is not what was expected!

Unknowns

As a BA it can feel like you’re expected to be an oracle, seeing into the future and coming up with the perfect solution upfront. 

Now while we can spend a great deal of time understanding the problem to be solved and potentially coming up with what appears to be the most appropriate solution, there are many variables not in our control that will impact what has been decided upon, such as:

• Changes to government legislation
• New technologies
• Leadership changes
• Competitors
• Newer, better ideas

When these variables change in the future, it means our perfect solution is not-so-perfect anymore and we need to amend our requirements. 

At later stages of a waterfall this can become painful, difficult and expensive. Now as humans, what do we do when something is painful, difficult and expensive? We don’t do it! In turn we deliver a solution that isn’t ideal. 

Lead time

The requirements gathering phase naturally takes time. There can even be hesitation when signing off on requirements. Why is that? Well if we only have one shot to get these requirements right, we’re going to make damn sure we get them right 🙂

In turn, there is a long lead time before our customers receive the solution and confirm that it meets their needs. The longer it is before they confirm their needs have been met, the greater the risk that the optimal solution will have changed.

What’s different about ‘requirements’ on an Agile project?

So Agile, by no means a silver bullet, is attempting to help us avoid these potential traps. How does it do this, and how does the requirements elicitation process change?

Firstly, rather than running our phases in a sequence, you could liken them to running in parallel with one another:

So that means BA’s aren’t involved only at the beginning of an Agile project, but constantly throughout. This reduces our lead time, and we start delivering value to our customers earlier.

Where does the Business Analyst get involved then? 

Most organisations now adopt the Agile framework ‘Scrum’. At the heart of Scrum, we have a cross-functional team. This team potentially includes programmers, testers and yes, you guessed it, Business Analysts 🙂

So what’s the big idea? Rather than having functional teams working independently of one another, we have small cross-functional teams where individuals from different functional groups work together. This eliminates barriers between individuals and minimises hand-offs improving the way the team communicates. 

What does a Business Analyst do on a Scrum delivery team? 

Your job as a BA is to ensure the team understands the needs of the customer, and delivers the highest business value possible, in the shortest amount of time. This effectively means you’re providing the team with a steady stream of requirements. 

To do this, instead of defining all the requirements upfront for the entire project, the requirements will be broken down into smaller deliverables, and the focus will be on the requirements that are most important at that point in time. This is what we call “Rolling wave analysis”. 

What does a Business Analyst document on an Agile Project?

This is where it gets tricky, especially when the Agile Manifesto promotes the value “Working software over comprehensive documentation” which has led to the widespread misconception that Agile teams do not document, which is not true. So what do you document then?

To help, think of the common Agile saying: 

Focus on outcomes over outputs

You will already be doing this as a BA, where you’re thinking about the needs (outcome) of a customer first over the solution (output) that we will give them.

So if we were to apply this to the role of BA, we might say:

Focus on the delivery of value (outcome) over documentation (output)

As an Agile BA, you need to ensure the team is delivering the highest value possible in the shortest amount of time, instead of focusing on documentation. So how can we ensure our team is delivering the highest value possible in the shortest amount of time? Does it require comprehensive documentation? Sometimes but not always. 

Agile Requirement Techniques

On an Agile project we want to be able to help our team understand the needs of our customers as rapidly as possible, so they can get started on implementing the solution. Comprehensive documentation may not be the optimal delivery method for our requirements.

So instead of comprehensive documentation, an Agile BA will leverage other techniques, such as:

• Lightweight documentation (User Stories, Job Stories, Use cases etc)
• Facilitate structured workshops to enable high-fidelity communication via face-to-face discussions
• Behaviour Driven Development (BDD) where our automated test suite becomes what is called ‘Living Documentation’, and automatically evolves as our application changes
• Carefully splitting requirements into increments that can be delivered iteratively, and prioritised by business value

Would you like to learn more about the Agile BA techniques mentioned above? Join us at an upcoming Virtual Agile Business Analyst course 

In summary

• An Agile BA now performs rolling-wave analysis through-out a project, rather than all upfront at the beginning
• Agile BA’s form part of the Scrum cross-functional delivery team
• The Agile BA is responsible for helping their team understand the needs of the customer, and deliver the highest business value in the shortest amount of time
• Agile BA’s become experts in delivering requirements rapidly by leveraging light-weight documentation, facilitating structured workshops, utlising techniques like BDD, and breaking down requirements so they can be prioritised

What next?

Checkout this worksheet. Print it out and fill in answers to the questions to help you improve your approach to Business Analysis on an Agile team.

Would you like to learn more about the Agile BA techniques mentioned above? Join us at an upcoming Virtual Agile BA course. 

Comments are closed.