What is an AGILE Business Analyst & Where do I Sit

This is a passionate, enthusiastic and strongly opinionated post.

It might not be everyone’s view.

BUT…

It will give you a clear idea of where a Business Analyst can fit into an Agile team.

I also provide an insight the different roles that a Business Analyst might play in Agile software delivery.

I even tell you what I HATE about Agile setups.

 

First: Agile is NOT a Project Management Methodology

You will often hear Agile being referred to as a project management methodology.

Here’s my view…

In software, Agile is about continuously improving while delivering value through a working product.

It’s ongoing and an evolving product is NEVER DONE!

It’s NOT about managing a project. Or about having a project manager dictating to everyone what they should be doing. Or coming up with fluffy delivery dates that no one will ever be able to meet.

Agile promotes a self organising team, which means that are accountable for delivering what they agree to on an iterative basis.

Agile Business Analysts write user stories not Requirements

This is the first lesson you need to learn if you’re going to thrive in Agile. The word ‘Requirements’ doesn’t exist in Agile.

Have you ever been in a team and someone has said “there wasn’t a REQUIREMENT for that”.

Well Agile seeks to remove this by allowing flexibility in requirements as the project moves forward.

And thiese come in the form of User Stories that can be slotted into the backlog at any point in time. User stories are simple to grasp but challenging to MASTER.

Especially true for traditional Business Analysts who are asked to write user stories.

 

Skills you need as an Agile Business Analyst

It doesn’t matter what people say where the Business Analyst sits.

There will always be a need for Business Analysis skills within any software or project delivery.

Whether those skills sit in the role of an actual Business Analyst job title, a Product Owner or a Developer title – it doesn’t really matter.

The fact is, they are still needed.

So everything you’ve learnt from this blog and from your past education/experience is still ULTRA relevant. Never forget that.

Read my post Business Analyst 37 Habits

Ultimately Business Analysts will ALWAYS be able to find their place within an Agile framework or team.

So here’s how you can make your transition from Waterfall to Agile Business Analysis A LOT easier.

With just a few practical tips.

 

Agile is an approach to delivering BA requirements

This is sooo important if you’re still a part of a team that writes User Stories.

Why?

Because understanding this will help you progress in your Agile career faster than any other.

As opposed to looking at Agile Business Analysis as part of a project management methodology.

See your role as an APPROACH to feeding your requirements to a team of people within a fast moving and changing environment.

Whereas previously, in Waterfall, your approach to delivering requirements would have been in a 200 page document that needed to be read AND signed by everyone.

What do I mean?

That instead of, as in Waterfall, trying to get a full understanding of every area of the system BEFORE sharing anything with the development team and stakeholders.

You need to share your evolving requirements with your product team EVERY DAY or WEEK. That will usually be as part of what’s called a backlog grooming session.

But, like in Waterfall, these requirements can be presented in any way you feel best such as:

  • Process Flows
  • User Scenarios
  • Wireframes
  • Detailed Designs

You should utilise the help of a designer to ensure consistency in your requirements/screens.

Sharing designs and flows with the team early will open up excellent discussion and fuel an even better shared understanding

And that’s one of the key reasons Agile exists.

For everyone to gain a shared understanding of requirements through conversation and discussion.

 

A Working Business Analyst Within the AGILE team

is this you?

If so, prepare to be adaptive technically.

Usually the Agile ‘inner’ team is made up of Developers and Testers.

But sometimes a Business Analyst will be placed within a team but still keep their job title as a Business Analyst.

Here you’re expected to be a more technical BA.

You might work closer with the database and write micro technical specifications with the help of developers.

On the other hand you may be asked to get your hands dirty with some testing or Quality Assurance checks.

If you’re extremely technical or have a background in coding, you may be asked to do a bit of coding. In fact you might even enjoy getting back in the coding hot seat for a few hours.

Either way.

You are part of the inner team. So you will be expected to help with the all-important “push” towards the sprint goal at the end of the sprint.

On the other hand, the Product Owner might ask you to help out with defining the sprint goal ready for Sprint Planning while funnelling user stories to the team.

This doesn’t mean the Product Owner can get out of working closely with the team. They need to be available for question and answer sessions when the team are struggling to find direction.

 

Coding, testing, technical, assisting with requirements / user stories. Could all be part of a BA role.

Business Analyst as a Proxy Product Owner

Personally, I HATE this setup.

Why?

Because it’s defeats the object of having a Product Owner in the first place.

One of the key benefits of a Product Owner having to manage stakeholder relationships AND write user stories AND present those to the team is…

QUICK DECISION MAKING.

So with a Proxy product owner it immediately delays decisions.

Why?

Because the ‘decision making’ Product Owner is likely busy with other stuff and often thinks they don’t need to be readily available to the team. They think the Proxy PO will answer all the questions.

But the Proxy doesn’t have the power to give the final answer answer because they need to clear it with the person that does make the decisions. Probably a manager that doesn’t want to let go of their ‘power’.

So to me…

This setup is an EXCUSE for management to cling onto their own control but without having to do the actual work that’s required from a Product Owner role. Which is the most important aspect for the project to move forward.

This leads me to the biggest challenge in a company when creating a Product Owner role during a transition to Agile.

Empowerment of decision making for the Product Owner.

For example:

Many managers like to say their BA’s are now product owners. But often the manager wants to remain as the key decision maker for the product.

It slows things right down.

It can work having a BA as a Proxy product Owner. BUT the Proxy should be working their way to becoming a full Product Owner.

AGILE Business Analyst as Product Owner

This is where you NEED to be extremely versatile and focused.

A true product owner juggles many tasks:

  • Stakeholder Management and engagement
  • Financial benefits / prioritisation
  • Business Analysis
  • User story creation
  • Backlog Grooming (User Story refining)
  • Workshop facilitation
  • Quick decision making
  • Product Promotions

To name just a few.

The good thing?

All of these tasks accommodate each other and the more you do of one, the better you will become at another.

For example, if you are in charge of making decisions and delivering the user stories, you will be AMAZING at selling your product. Or what feels like your product.

It’s not easy to become a full Product Owner.

But if you work hard to master the above skills, your career will fly. And you will be earning dollars before you know it.

A final Note on Agile Business Analysis

Don’t worry about your actual job title.

It’s all about the tasks you’re fulfilling that will make you who you are tomorrow.

SO there you go. The different ways you can transition yourself to working as an Agile Business Analyst.

Start today, AGILE  is the present and future of software delivery.

The BA of tomorrow needs to be dynamic, enthusiastic and adaptive to the changing demands of environments.

 

 

Leave a Reply

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