This is the fourth 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.
Once you’re oriented to the context in which you’re working and you’ve established a shared understanding of the outcome you seek, it’s time to identify the scope of your work.
When you’re working in a situation with a great deal of certainty (you have a clear understanding of what needs to be done in order to accomplish the desired outcome) you can represent your scope as the collection of backlog items. Sort of.
You see, backlog items are options.
Just because an item shows up on the backlog does not mean it has to be done. Your gauge on whether something has to be done is the impact on your desired outcome.
In some cases, almost all the items you put on your backlog need to be done. This is often the case in initiatives with a lot of certainty – where you’re replacing an existing system for example. In many cases however, there is a great deal of uncertainty regarding the best way to accomplish something. In those cases, backlog items take on the role of options. You can’t know at the beginning of the effort the best way, so you put items on your backlog that will help you determine the best approach. As you deliver some work and see the impact on your desired outcome you’ll build a better understanding of what you need to do and the ratio of items on your backlog that are necessary will grow.
The key is to not use scope – defined as a list of backlog items – as the ultimate measure of success. That should be the outcome based metric you already identified. Your backlog can still serve as “our current understanding of scope” with the realization that understanding will change as you proceed. This is one of the key ideas behind design thinking – understand there may be multiple ways to solve their problem so you experiment with different solutions to find the one that works best.
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.
Key Responsibilities
Defining a solution approach to determine the nature and extent of technology and business process changes to be made as part of implementing the solution to the primary business objectives.
When you’re in a fairly certain environment, you can identify a solution and then populate a product backlog from that view of the solution. If you’re doing work to support a business process, you may find it helpful to create a process model and use that to identify backlog items. You may also find a story map helpful to understand the entire process you’re trying to support and to identify potential ways to support that process.
When you have an outcome identified, but are not sure the best way to get there, an Impact Map can be extremely helpful. You start with your outcome, identify the people who can help you reach that outcome or prevent you from reaching that outcome, determine the behaviors that will drive those impacts, and then determine the deliverables that you can deliver to help change those behaviors. After each deliverable you deliver, you check the impact on the objective and then decide whether you are done or if you need to try another deliverable. These deliverables are the input to your product backlog, but you only want to have the deliverable you are currently working on in the backlog.
Keep in mind that you’ll more than likely have more items in your backlog than you’re going to deliver. The backlog represents things you could do, not things you absolutely have to do. The backlog also represents your understanding of scope at the moment, not the final definition of scope.
Drafting a scope statement and reviewing it with your key business and technology stakeholders until they are prepared to sign-off or buy-in to the document.
When you work in an agile fashion, your agreement and commitment with your stakeholders is not based on scope, but rather reaching a specific outcome. You don’t have a scope statement that addresses your agreement. You agree on the outcome you seek to deliver (described using an outcome based metric) and then you establish a backlog with potential ways to achieve that outcome. You review your progress on a regular basis with your stakeholders and confirm whether the backlog has the appropriate items in the appropriate order in it.
There is no single sign off. Rather, there are a series of agreements to proceed for the next couple of weeks based on what everyone understands at the time.
If you’re using sprints, sprint reviews are a good time to re check those agreements.
If you’re working in a flow approach you may check progress after every item is completed, or on a regular cadence once every week or two.
Confirming the business case to ensure that it still makes sense for your organization to invest in the project.
A part of those ongoing discussions and agreements is a discussion about whether the problem is still worth addressing at all, and whether it’s worth it to address the problem with the chosen solution.
Evaluate whether your effort is worth it on an ongoing basis because as you deliver new outputs and check the impact on the outcome, you’re learning more about the problem and possible solution(s). You may find that you learn something which indicates that it’s going to cost more to solve the problem than the problem is costing to not address it.
Or, you may find out that there’s a different solution which you can use to address the problem for less.
Up Next: Formulate Your Business Analysis Plan
The next step in Laura’s business analysis process is to formulate a business analysis plan. That process assumes a fairly linear process.
When you work in an iterative fashion where you repeatedly deliver small portions of the overall solution, gather feedback from the things you’ve delivered and decide next steps. Instead of a plan, you identify what practices you follow in those cycles. The next post will describe how to go about identifying the practices you use on a repeated basis.