You are not an agile business analyst just because you have a working knowledge of Scrum, you are able to write user stories, or because you got a certification.
You are an agile business analyst when you focus on outcomes over outputs, use short feedback cycles and adjust when and to what extent you use the analysis techniques you’ve used your entire career.
Outcome is the change you’re trying to introduce to the world. It’s why you’re doing a project. Outputs are the things you produce in order to satisfy that need, or the solution. One of the most relevant categories of outputs for business analysts are requirements and the related deliverables and artifacts.
You no longer define your role as eliciting and analyzing requirements and producing artifacts (output). You define your role as positioning your team to deliver the desired outcome by keeping them focused on that outcome, building a shared understanding and making sure decisions get made.
You use most, if not all, of the analysis techniques you’ve used before but the reason you use them is different.
You don’t use an analysis technique to produce an artifact that serves as the primary (perhaps sole) means of communication. You use analysis techniques to build and maintain shared understanding between the team and stakeholders. If you produce an artifact to remember what that shared understanding is, great.
Instead of using visio alone at your desk, you use a whiteboard collaboratively with your team and stakeholders.
During those conversations you learn more about your customers and users and their needs. You learn more about the constraints that your stakeholders want to apply to your project.
You learn at each step of the software development lifecycle. You learn about your solution when you build parts of it. You learn about your solution when you test it. You learn about your solution when customers look at it and users use it.
These are all feedback cycles, and you want them to be as short as possible so that you can learn quickly and make sure you stay headed in the right direction. To make the most effective use of those feedback cycles, you don’t want to get too far ahead of what’s getting built next. There’s certainly value in understanding the breadth of what you’re trying to deliver but you don’t want to dive deep on everything too soon. The key phrase is mile wide and inch deep followed by repeated cycles of inch wide and mile deep. Establish the general parameters of what you’re going to tackle and then do deep dives on small aspects of the overall solution when you need to.
Laura Brandenburg describes business analysis in terms of an 8 step business analysis process which she uses as the foundation for her BA Essentials Master Class. In upcoming posts, I’ll take a look at each step through an agile lens. As part of that view, I’ll take a look at what the key responsibilities associated with each step look like.
Here are the 8 steps:
- Step 1 – Get oriented
- Step 2 – Discover the primary business objective
- Step 3 – Define scope
- Step 4 – Formulate your business analysis plan
- Step 5 – Define the detailed requirements
- Step 6 – Support the technical implementation
- Step 7 – Help the business implement the solution
- Step 8 – Assess value created by the solution