Just Enough Doesn’t Mean None! The Agile Business Analyst Role-EN

In an amazing turn of events, I have recently been teaching and consulting in organizations that have transitioned to an agile framework AND have decided, as part of that transition, that business analysts are no longer needed. In this blog post, I would like to note where I think this mentality came from and then argue against it.

The agile approach grew out of the Agile Manifesto and is typically implemented with some Lean and Just-In-Time concepts incorporated into it. There’s a statement in the Manifesto, “working software over comprehensive documentation,” that not only has been misinterpreted to mean “we don’t need no stinking documentation” (with a nod to Blazing Saddles), but it has also been misinterpreted as “since we don’t need documentation, we don’t need business analysts”! Huh?!

I’m not sure why the business analyst role in many companies is viewed as just “that person who writes down our requirements”, but I see it all the time. Many business analysts are seen as note-takers rather than analysts. Taking notes is not how we add value. Analysts, regardless of title, have the skills to facilitate conversations, which is at the heart of agile. Helping the business get the most value for their money by determining what problems should be solved and how to solve them is the primary part of what we do in the analyst role. Writing requirements is only a small piece of that and is definitely not the most important (but it is certainly not useless).

Written requirements are great for communication, reuse, and capturing history and corporate memory. With agile, we must find the right balance between conversation and the right amount of documentation. Through training and experience, effective teams determine the appropriate balance and decide which techniques will best support their communications. Some of the most important aspects of our role as business analysts are:

• Challenging the organization
• Helping ensure that resources are directed towards what should be done based on business value
• Making sure that initiatives are providing the benefits expected

Why would these skills not be needed on an Agile initiative?

So, what role does an agile business analyst play? Let’s explore the life cycle of an initiative or project (yes, I know we don’t like to talk about life cycle in agile, but there is a life cycle to producing a solution, whether that cycle is iterative or not!).

Scope (aka Product Vision or Iteration)

Yes, initiatives or projects need to be scoped, even in an agile world. However, it is more commonly referred to as Product Visioning or Iteration 0. What does that mean? From a business analysis perspective, much of what goes into scoping is understanding the problem to be solved, the root cause of the problem, why it is a problem, whom it affects, and understanding what solving that problem will do for the business.

We should also be helping the business understand and calculate the business value a project will provide, including:

• What should be measured?
• How will we measure it?
• Is this initiative worth the cost and effort? Have we analyzed, documented, communicated, and planned for risk?
• Do we have the right people involved?
• Do we understand all the impacts?
• What is the minimum amount of work we can do while still solving the problem and sufficiently mitigating risk (many call this minimum viable product or MVP)?

Yep, all this still needs to be considered in the agile world!

Business Requirements

Coming out of Iteration 0 are high-level requirements, which are business requirements. I’m talking about true business requirements; this entails a deep understanding of what our business does, agnostic of technology. Why agnostic of technology? Because if you don’t understand what your business does and how it does it logically (not technically), how do you understand how to automate what it does?

Yep, this is still needed in an agile world!

Roadmap Planning, Release and Iteration Planning

Through the Roadmap, Release, and Iteration Planning stages, business analysts provide a progressive elaboration of the requirements in the form of features, user stories, and acceptance criteria. A good business analyst is crucial in helping the business prioritize features and user stories based on MVP so that designers and developers have a generalized roadmap for iterations or sprints for future conversations.

An agile business analyst helps the product owner with the user story preparation so that the user stories have sufficient detail when the iteration starts. The analyst can also ensure that acceptance criteria is captured so that the developer can understand all pertinent scenarios and quality assurance can generate the appropriate test cases. The user story acceptance criteria should be in a “ready” state before it is assigned to a sprint.

Yep, all this is still needed in an agile world!

Transition Requirements

The business analyst should be key in determining how the business will transition the solution into production. In agile, these requirements are captured as a special story or work item in the backlog. Whether you are releasing every two weeks, four weeks, quarterly, yearly, or some other interval, you should not be just putting features “out there” without planning the change.

The business analyst may be assisting in activities such as communicating changes, analyzing data migration strategies and requirements, and determining transition strategy (parallel, cut-over, pilot, rolling wave). And, although we should never need it because we are such awesome business analysts that we prevent it (!), we may need to help determine a back-out plan in case things go awry.

Yep, all this is still needed in an agile world!

So, let’s go back to the “we don’t need no stinking documentation” statement. All the great analytical activities I’ve mentioned above are valuable. Without them, a project will typically have scope creep, missing requirements, incorrect requirements, misunderstandings, frustrations, bad results, unhappy customers (need I go on?). Do we need to document the results of those great analytical activities? Yep, even in an agile world!

We know that we can’t trust ourselves to simply keep all this information in our heads (or even in our code); we need documentation to keep everyone on the same page and for remembering why and how we did what we did.

Does that documentation have to be formal, in fancy tools, and voluminous? Not necessarily. My approach is to determine my documentation needs at the beginning of the project, based on the type of project, legal responsibilities, Sarbanes-Oxley responsibilities, stakeholders with whom I need to communicate, tools available, etc. Just like MVP for the solution, I determine MVD (minimum viable documentation) for the project. I want the perfect amount for the particular project, not one word more or one word less!

Each team needs to have a serious conversation about what’s just enough and just in time documentation and what skills and resources are available on the team to do it. Bottom line, we still need good business analysis and good documentation for our organizations, maybe even more so in this fast-paced ‘agile’ world!

Download our Agile BA Checklist to be sure that at least one person on your team has the skills necessary to perform these activities.

Because someone with strong analytical skills should be doing these critical activates throughout the agile project life cycle.

Thank you,

– Ali