This is the fifth in a series of posts that take a look at the agile business analyst in terms of Laura Brandenburg’s 8 step business analysis process which serves as the foundation for Bridging the Gap’s BA Essentials Master Class. Go to The characteristics of an agile business analyst for an introduction to this series.
Perhaps the biggest difference between business analysts in a phase based approach (often derisively referred to as “waterfall”) and an iterative approach (commonly referred to is “agile”) is when you do a majority of your work. In most phased based approaches, you perform all of your analysis at the beginning of the project in order to create a sometimes quite substantial requirements document.
In an iterative approach, that aspect of analysis gets spread throughout the entire initiative. You do a little bit of work to establish the breadth of your initiative at the beginning, but you stay at a fairly high level. Then, as your team starts to deliver small increments of the solution you do a deep dive into each subset of the solution as needed. Your analysis work gets spread throughout the initiative to the point where you’re doing a deep dive on the backlog items that your team will most likely deliver next, while they’re working on backlog items that they plan to deliver now. I’ll explain more about what that looks like in the following posts.
This change in when you do analysis means that you need to dramatically reconsider what you think of when you hear “agile business analysis plan”.
The business analysis plan was always about setting expectations with your team regarding the output of your analysis efforts, but most people looked to the plan as a list of people to talk to and documents to produce.
When you work in an agile fashion, it’s helpful to focus in on the expectation setting aspect of the business analysis plan. You’re in effect forming an agreement – dare I say shared understanding – about what information, and what format, you and your team will use to build a shared understanding about the solution you’re going to deliver.
The techniques I’ve found most helpful to build and maintain that shared understanding are the discovery board and the definition of ready, along with a health dose of refining that understanding during retrospectives and general discussions among the team.
You and your team may also establish some agreements about what system documentation you want to create and maintain while you’re building the solution so you have reference information for future efforts.
You’ll see more about how to use those techniques in the discussion of the key responsibilities below.
How To Be An Agile Business Analyst
As a business analyst, you have probably wondered how agile impacts your work. You may look at the popular agile frameworks, notice that business analysts aren’t mentioned and wonder whether you fit.
The key is to not focus on the frameworks and prescriptions, but rather to apply your business analysis skills in an agile manner so that your team solves the right problems with the right solutions. How To Be An Agile Business Analyst shows you how.
Read How To Be An Agile Business Analyst to uncover ways to add value to your organization, make your team more effective and build a more rewarding career.
Choosing the most appropriate types of business analysis deliverables, given the project scope, project methodology, and other key aspects of the project context.
You want to reach an agreement with your team about what information they would find helpful to start developing a part of the solution represented by a backlog item. You also want to come to agreement on what format is best to convey that information.
I hesitate to call those items “business analysis deliverables” because they really belong to the entire team, but chances are the things that get produced (jointly by you and the rest of your team) are going to look awfully familiar. As you’ll see in the post about defining detailed requirements, the techniques you use to describe backlog items are often some of the more frequently used business analysis techniques.
In order to help come to an agreement about how your team will communicate and remember the specifics about the solution and individual backlog items, it’s helpful to create a definition of ready. The definition of ready indicates the information that your team would like to have in place to consider a backlog item for inclusion in a sprint. It’s how you know the backlog item is “ready” for development work to begin. It also is a good indicator as to when you’ve done enough analysis on that backlog item.
You jointly create the definition of ready with your team, and you revise that definition based on your team’s experience of delivering backlog items and your experience of guiding the effort to get those backlog items ready.
Defining the specific list of business analysis deliverables that will completely cover the scope of the project and identifying the stakeholders who will be part of the creation and validation of each deliverable.
There’s a great deal of overlap between this key responsibility and the previous one, especially when your perspective on requirements changes from an end in and of themselves to a means to an end.
The one thing additional thing that this responsibility drives is what system documentation your team needs to maintain. System documentation is that reference information you want to keep around after you’ve delivered your product so you have something to reference when you need to make changes in the future.
The items usually identified in the definition of ready are “project documentation” that are helpful to note the changes from the current state of the product to the desired new state. Those items usually aren’t organized in a very helpful manner for reference and maintaining the product on an ongoing basis.
That’s where system documentation comes in handy. It’s built with the purpose of being easily referenced, and easy to maintain. There’s no need to duplicate information that can be derived directly from the product itself. The system documentation should provide supplementary information not immediately apparent in the product.
Another aspect of this responsibility is identifying the key stakeholders that you need to interact with in order to successfully deliver the product. A stakeholder map can serve as a guide for determining how to interact with those stakeholders, but you still need to actually interact with them.
Identifying the timelines for completing the business analysis deliverables.
Due to the switch from creating a set of deliverables at the beginning of a project to fleshing out the specifics of certain work items on a regular basis, the concept of timelines and deadlines takes on a different meaning. Instead of having one significant timeline, you have repeating targets for getting product backlog items ready, which usually correlates to right before sprint planning.
I’ve found the discovery board helpful in making the progress of backlog items more transparent. You aren’t necessarily going to have a series of timelines so much as a visual display of where items are and whether you’ll have enough to sufficiently fill up your teams capacity.
Up Next: Define the Detailed Requirements
The next step in Laura’s business analysis process is to define detailed requirements for your solution. As with this step, you’re shifting from defining all the detailed requirements at the beginning of the project to doing small deep dives throughout the entire effort.
The next post describes how to go about doing a deep dive into a backlog item and balance the right amount of information communicated in the right way.