This is the third 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.
You’ve probably been in this situation before. You start work on a new product, or want to change an existing internal product. It’s an exciting time, there’s work to be done. You can really make a difference.
You’re tempted to pull everyone together into a room and start putting up sticky notes with all of the great things you could do…
I think perhaps you’ve forgotten something.
- Why are you building or changing that product?
- Do you know what problem you’re trying to solve?
- How do you know if you’re heading in the right direction?
- How will you know when you’re successful?
- Do you know your why?
Unfortunately this is all too common. You have the irresistible urge to jump right into defining what you need to do – identify your outputs – without first clearly understanding why you’re doing something – understanding your desired outcome.
If you determine your outcome first, and express that in a measurable fashion, you can use that as a decision filter to focus on the things that absolutely have to be done and avoid those things that don’t contribute to what you’re really trying to accomplish.
Do you have to wait until you fully understand your context before you identify the desired outcome? Not necessarily, You do need to identify the customers you are trying to serve first in order to understand the problem you’re trying to solve, but you need to know the problem you’re trying to solve in order to know what stakeholders may be involved.
This is just as important in an internal situation as it is in an external situation, perhaps even more important.
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
Discovering expectations from your primary stakeholders – essentially discovering the “why” behind the project.
When you work on an internal product, you need to decide what to do based on it’s impact to your customers, but you also need to consider your stakeholders. Chances are those stakeholders are the users of the internal product, or have the users working for them. As a result, they are going to be very interested in what you’re up to. It can be easy for those stakeholders to be more concerned about their own needs than considering your actual customers’ needs.
In an earlier post I shared some ways that you can start work on an internal product which include:
- Establish a relationship with the sponsor (the business leader who wants to make sure the problem is solved)
- Discover the desired outcomes
- Establish decision making guardrails
- Build a shared understanding with your team
There are three techniques I’ve found particularly helpful for discovering the “why” for your effort. In all three cases, these techniques are ways to structure a conversation between the key players in your effort in order to identify the true why behind your effort.
The Internal Product Opportunity Assessment is a set of 10 questions to help lead your team, including your key stakeholders, through a discussion in order to identify why you want to do something and whether it’s worth it.
The problem statement may form an answer to one of the questions in the opportunity assessment, or it can act as a shorter version of that exercise. This technique helps you identify people’s current view of why you’re taking on a specific initiative and then provides a way of coalescing to a shared understanding.
Creating a project charter with your team and stakeholders can be a great way to discuss all the key points and come to a shared understanding on why you’re pursuing the effort. There are several different formats that teams have found useful. All of those different approaches have the following characteristics in common:
- Your output is concise – usually a page in a length.
- Your team has a shared understanding for the problem you’re trying to solve.
- Your team has a shared understanding of how you’ll know when you’ve solved that problem.
- You’ve identified any constraints which will impact the solution.
Reconciling conflicting expectations so that the business community begins the project with a shared understanding of the business objectives and are not unique to one person’s perspective.
You satisfy this key responsibility by holding collaborative discussions with your team and stakeholders, so no additional techniques are needed to accomplish this key responsibility.
You could head offsite, hole yourself up in some cabin in the woods, write out a problem statement and then ask everyone on your team to read it and live it.
The problem with that approach is that your team and stakeholders do not get an opportunity to internalize what the project is about and clarify their viewpoints about it. If they rely on reading the description about the product they will either interpret what they read to match their preconceived notions, or won’t bother to read the document at all.
Ensuring the business objectives are clear and actionable to provide the project team with momentum and context while defining scope and, later on, the detailed requirements.
In order to truly know when you’ve delivered the outcome that you sought to deliver or solved the problem you set out to solve, you need some form of outcome based metrics. These are measurements that tell you quantitatively that you have helped your organization achieve some form of outcome, not merely delivered a specific output.
When defining outcome based metrics, I’ve found the characteristics of good objectives that Tom Gilb suggested in Competitive Engineering to be particularly helpful:
| Attribute | Description | Example |
| Name | Unique name for the objective | New/renewed memberships per month |
| Units | What to measure (Gilb refers to this as scale) | Individual members |
| Method | How to measure (Gilb refers to this as meter) | Sum of new memberships and renewed memberships within the month |
| Target | Success level you’re aiming to achieve | 300 members/month |
| Constraint | Failure level you’re aiming to avoid | 200 members/month |
| Baseline | Current performance level | 250 members/month |
An important aspect of value that comes out of setting these attributes is the discussion that occurs in order to decide what the target and constraint should be, as it allows the team to get a clearer understanding of what success looks like.
Understanding the desired outcome in terms of outcome based metrics gives you the opportunity to build a shared understanding with your team surrounding why you are considering starting (or continuing) a particular project. It also gives you a basis for asking the question “Is this need worth satisfying?”
Up Next: Define Scope
Once you define your outcome and build a shared understanding of that outcome with your team and stakeholders, you now can discuss different ways to deliver that outcome – your possible solutions. These potential solutions give you an idea of what outputs you need to provide and help you identify your scope.
The next post in the series describes how to create a focused scope based on the outcome you identified.