Following is an excerpt from How To Be An Agile Business Analyst, a book that explores how to apply your business analysis skills in an agile manner so that your team solves the right problems with the right solutions. Get the book now to uncover ways to add value to your organization, make your team more effective and build a more rewarding career.
You are not an agile business analyst just because you have a working knowledge of Scrum, you are able to write user stories, or you got a certification.
You are an agile business analyst when you consider your context so that you use appropriate techniques. 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 are an agile business analyst when you help your team focus on delivering maximum outcome with minimum outputs and use that outcome to define success and measure progress.
An outcome is the change you’re trying to introduce to the world. It’s why you started a project to make changes to your product. Outputs are the things you produce—like requirements and the related deliverables and artifacts—in order to satisfy that need, or the solution.
As an agile business analyst, you no longer define your role as eliciting and analyzing requirements and producing artifacts (output). Instead, you position 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 no longer define the goal of your team as producing outputs; it’s to reach a specific outcome. A successful team seeks to maximize outcome with minimal output. That way, you get as close to the desired change in your organization and your stakeholders’ behavior as possible with the least amount of initial and ongoing work.
You are an agile business analyst when you use tried and true business analysis techniques to build and maintain a shared understanding of the problem your team is trying to solve. You use most, if not all, of the analysis techniques you’ve used before, but you use them for different reasons.
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.
Yes, business analysts elicit and document requirements, but those activities are just means to an end. Analysis is about understanding your stakeholders and their needs, identifying the best solution for satisfying those needs in your context, and then building a shared understanding of that solution. Requirements play a part in that work, especially around describing the need, but they are certainly not the end product.
When the teams I worked with thought that the business analyst’s sole responsibility was requirements, my role was diminished and I lost the ability to make sure the team delivered the right thing.
Things were different when I stepped up, sought to understand why we were working on the project in the first place, and then made sure everyone on the team had the same understanding. The project went better, I enjoyed my work a lot more, and I found I had much more influence on that project and in the organization.
You are an agile business analyst when you make sure decisions get made, whether you have the responsibility for deciding or not.
You are an agile business analyst when you use short feedback cycles to learn about your users’ needs and adjust your product accordingly.
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 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 “a mile wide and an inch deep,” followed by repeated cycles of “an inch wide and a 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.
Let’s take a closer look at the five things that make you an agile business analyst.
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.
Consider context
“It depends.”
The annoying, but honest, answer given to most questions about product development. If someone provides that answer and stops there, they’re trying to avoid the question.
If they say that and then continue to explain what happens in various situations, they are admitting the impact of context in product development.
The impact of context prevents best practices from being a real thing. The term “best practice” frequently describes techniques or processes that were successful for one team or organization and are being copied by others.
Unfortunately, what works for one team may not work as well in your situation. Many environmental factors can play a role in the effectiveness of a practice for a given team. For this reason, I typically say “appropriate practices” or “good practices,” emphasizing the fact that there really are no best practices across all situations.
Your team has to consider your environment, your organization, and your product when choosing which processes, practices, and techniques you’ll use, so you can be sure you’re doing whatever will make them successful—and skipping anything that’s not necessary.
Perhaps considering context is the only real best practice.
Focus everyone on maximum outcome with minimum output
Outcomes are changes in the world that happen because of your work. With internal products, outcomes show up as changes in the organization or in your stakeholders’ behavior. You deliver outputs in order to achieve some outcome. Outputs can include code, tests, requirements, and documentation.
Gojko Adzic suggests another way to describe outcomes and outputs. You can look at outputs as effort spent or invested and outcomes as what your customers get as a result of that investment.
Because outputs are typically easier to measure than outcomes, most teams and organizations measure progress and define scope by the number of outputs produced. But it’s possible to produce a large number of outputs, spending a lot of money in the process, and still not reach the desired outcome.
It’s better to focus on the outcome that you want, and then as a team determine the minimum outputs necessary to deliver that outcome. This shortens the time required to deliver the outcome, reduces the cost of producing the outcome, and decreases long-term costs, as you have fewer outputs (code, tests, documentation) to maintain.
The secret is to build a shared understanding of the problem your stakeholders are trying to solve (outcome) and then determine the most appropriate solution (output) for realizing that outcome.
Don’t take all stakeholder requests verbatim; instead, dig a little deeper to understand what’s behind each request. Observing people at work is a great way to dig deeper. You may not immediately know what to ask about, but you’ll notice things when you watch your users.
Consider the information you get from talking with and observing your users, then decide whether the stakeholder request is relevant to your given solution. If it is relevant, determine the underlying need that the stakeholder is trying to satisfy, and tackle that need. If the request is not relevant, explain to the stakeholder why it’s not appropriate to address right now.
Once you understand the outcome you’re trying to deliver, as well as the assumptions underlying that outcome, use that information to guide what you do next. Select the outputs (often expressed as features) that allow you to make progress toward the targeted outcome, or that help validate assumptions. Which aspect you focus on first depends on how far along you are toward reaching the desired outcome. At first you’ll spend more effort validating assumptions (you can also think of this as reducing uncertainty), then delivering features that you know provide the value you seek.
The key point here is to identify value first, then iteratively identify the features that you need to deliver that value. Don’t brainstorm a big list of possible changes and then try to figure out how much “business value” each feature could contribute. Measuring value at the granularity of a user story is very difficult and wastes effort. Too often, a team spends time overanalyzing the value points associated with a story when they could easily have made a priority decision in another way. By working from outcome (value) to output (features) instead of in the other direction, you’ll have fewer items to manage at any point and you’ll avoid the tricky business of assigning value to any specific change.
In addition to delivering only required outputs, deliver those outputs using only necessary activities. In practice, this means that the approaches your team uses should be barely sufficient (with adjustments along the way as needed, based on experience).
Don’t get too hung up on the arcane semantics of modeling techniques. You’re using models to aid with communication and build a shared understanding. Imperfect is okay as long as everyone involved in the discussion understands what the model conveys. You can always chat to clear up any confusion.
Complicated processes or frameworks are rarely good ways to address complexity. The more complicated a process is, the less likely people are to follow it effectively—and, perversely, the more likely they are to hide behind the complicated process, to the detriment of the entire team. Keep your processes simple, and adjust them as you learn.
Build and maintain shared understanding
In a good collaboration, team members commit to meeting a joint goal, and they’re not afraid to step outside their area of specialization to help others on the team. All team members have a specialty (such as development, testing, or analysis) on which they spend a considerable part of their time. But when the need arises, they should be able to jump in and work on something else to help the team meet its overall goals.
As a business analyst, this might involve:
- facilitating whole-team collaboration
- helping other team members improve their analysis skills
- helping other team members be more effective with discovery
- using team member and stakeholder insights to aid in analysis
- helping out with testing and documentation when other team members get stuck
- taking advantage of different perspectives
Don’t hoard all the analysis work for yourself, or restrict your team members’ contributions to it.
Make sure decisions get made
Success in many types of organizations (for-profit, not-for-profit, governmental) depends on making well-informed, timely decisions. When I’ve worked on successful projects in successful organizations, the one common characteristic was clear decision making. Conversely, in less successful cases, a common factor was poor (or nonexistent) decision making.
An important aspect of decision making is who makes the decisions. That person should be as informed as possible and be in a position to make the decisions stick. In many organizations, the people expected to make most decisions—senior leadership—are not the best informed; leaders may not have the in-depth knowledge required to make a good decision.
You can resolve these issues by spreading decision making throughout the organization. This helps ensure that the people with the relevant information are the ones who make certain decisions. A prime example is teams deciding the best way to approach their work, assuming they have the proper understanding of the desired outcome and understand the constraints under which they must work.
Operate in short feedback cycles to learn
Unlike operational work, internal product development rarely uses directly repeatable processes. When you’re engaged in operational work, such as assembling a vehicle or processing a claim, many of the steps can be copied directly from one unit to the next. Identifying improvements becomes easier because there is very little time between cycles of a particular set of work tasks. Operational work is repetitive and fairly predictable; you can always learn how to do it better.
In contrast, no two product development efforts are alike. Even if you get the opportunity to work on multiple products, the lessons you learn from one probably aren’t exactly applicable to another. You can note patterns and trends, but each experience will be a little different.
A focus on continuous learning, with iterations being a key component, reminds your team to stop every so often and figure out what they can revise. This also helps you identify meaningful milestones, with progress shown as actual working output rather than intermediate artifacts.
It’s important to validate assumptions early in your project, so you can determine whether you have identified the right solution to the right problem. Asking your stakeholders for feedback is helpful but, due to the influence of cognitive biases, they could give you misleading information.
The Build-Measure-Learn loop provides a way to validate assumptions in conjunction with talking to your stakeholders. It also encapsulates the overall approach to building and getting feedback, which is a key aspect of the guiding principle to reflect and adapt.
Figure 1. The Build-Measure-Learn loop echoes Walter Shewhart’s Plan-Do-Study-Act cycle but emphasizes getting through the cycle as quickly as possible so the team can validate assumptions and test hypotheses about solutions.
Quick cycles through the Build-Measure-Learn loop can help your team reduce the uncertainty that often comes along with products. Start by tackling the biggest or riskiest assumptions. Eric Ries calls them the “leap-of-faith assumptions,” but it may be easier to think of them as the assumptions that, if proven wrong, can significantly reduce the chances that you deliver the desired outcome. For example, when I was working on a recent product we identified outside as the biggest source of risk, so we chose to build those interfaces out first, even though the related data were used at different points in the overall business process.
It’s also helpful to keep a mindset of identifying the right solution rather than iterating on a known solution. One way is to ask, What is our biggest unknown that would drive a change to our priority list?
Your team should continuously learn from its experiences if you want to improve your approach and your outcome. Specific projects often last longer than a couple of months. During that time, business conditions, team member understanding of the outcome, and the environment surrounding the product will all grow and change. Your team should seek to use that change to its advantage, to ensure that your outcome meets the needs of your stakeholders when the result is delivered—not just the perceived needs of the stakeholders when you started.
Project teams have long done postmortems or lessons learned sessions where team members gather at the end of the project to talk about what happened—usually the negative aspects—in hopes that they can do better next time.
If that end-of-project analysis is considered a good practice, wouldn’t it make sense to do the same thing while you’re working on a product, when the team still has time to make changes that affect the outcome? This is the idea behind retrospectives which provide teams with a mechanism to discuss what has transpired to date—things the team did well, along with opportunities for improvement—and decide what course corrections should be made.
A recent example
I was the product owner for the initiative to revise the Agile Alliance website, membership, and conference registration systems. When it came time to do a deep dive into the membership aspects of the system, I took it upon myself to write up all the specifics about membership— what information we wanted to track about members, what rules were relevant, and what types of memberships we had. It was a short yet comprehensive set of requirements. I was admittedly quite happy with them.
Until the delivery team started developing functionality without seeming to pay much attention to the requirements.
At first, I was perplexed. Did I not clearly tell the team where the requirements were?
Then I was irritated. Why weren’t they paying any attention to my carefully crafted backlog items?
Then it occurred to me that I had focused on the requirements as an output, without considering how it contributed to our desired outcome—increased membership. I didn’t talk with the delivery team to find out the best way to share information with them as they built the various aspects of the membership functionality. We didn’t have conversations as we went along to point out the relevant rules and pieces of information for the specific backlog item that they were working on at the time.
So we changed how we communicated. We still used the rules and data element information, but we used them more as reference points in the frequent conversations we had. We started relying on examples as we talked through the specifics of a given backlog item. We found that it was not enough for me to simply write those examples down. In many cases, the real advantage came from talking through them as the delivery team was starting on a backlog item.
I should have known better than to start the way we did. But it’s easy to forget good practices when you’re in the thick of it and the pressure is on. Here are some good practices I hope you remember when you run into the same situation:
- Take time to talk with your team about how you want to work and the best way to communicate information in order to build and maintain a shared understanding. When you have those discussions, don’t be afraid to suggest approaches that your team is not familiar with if they are applicable to your project.
- Document requirements collaboratively during your discussions, to build and maintain a shared
- Stop thinking of analysis in terms of gathering and capturing requirements, and instead think of it as solving problems and building a shared
One time we can talk about how
If you’ve been doing business analysis for any length of time, you’re probably used hearing that you should focus on the what, not the how. That is true. However, when it comes to talking about being an agile business analyst, it’s okay to break that rule.
We just discussed five things you need to do to be an agile business analyst. Chapters 4–11 describe in more detail how you go about doing that.