I had the opportunity to take part in the creation of version 2 of the Agile Extension to the Business Analysis Body of Knowledge. This was a great opportunity to shape the broader conversation on the intersection of agile and business analysis.
One of the things that I’m particularly pleased about the Agile Extension is that we (Steve Adolph, Shane Hastie, James King, Ryland Leyton, Jas Phul, Paul Stapleton, Stephanie Vineyard and I) were able to explain how business analysis is involved in making a variety of decisions at three different horizons. It’s important to understand these decisions because business analysis is often required to compile the information necessary to make these various decisions.
The concept of horizons is not a uniquely agile idea, nor is it a uniquely business analysis idea. All product people have to make sure these decisions get made. The iterative nature of agile approaches with short feedback cycles makes it especially important to introduce this concept in order for efforts to be effective. It’s also important to describe these decisions from a business analysis perspective to reinforce the role that business analysis plays in making these decisions.
I thought it’d be helpful to discuss the typical decisions that occur in each horizon, and the techniques that I’ve found helpful to address those decisions. Thanks to Kupe Kupersmith whose work inspired this exploration.
You can find out more about the Horizons from the Agile Extension to the BABOK Guide version 2 – Available free to Agile Alliance Members or IIBA Members or available for purchase on Amazon (affiliate link).
Strategy Horizon
The strategy horizon is where you consider the needs of your customers in relation to your organization’s strategy to determine what initiatives you do and do not do.
At least in theory that’s what is supposed to happen.
Some organizations don’t really consider their customer’s needs when they determine what IT initiatives to undertake.
Some organizations don’t have an actionable strategy that helps them make decisions.
Some organizations don’t decide what they aren’t going to do. (As important a decision as deciding what they will do).
There are two primary decisions about every idea at the strategy horizon. These decisions are generally made by Product Managers in a externally focused product setting and someone with portfolio management responsibility in an internally focused situation.
Is it worth it?
You’re really trying to decide if you have a need worth satisfying.
In order to make that kind of decision you should know:
- The actual need (not just a symptom)
- The impact on your organization’s customers. In other words are you directly addressing a customer need or are you addressing the need of a stakeholder inside your organization that will impact your customers.
- Whether the benefit experienced from satisfying the need outweighs the cost of satisfying it. In some cases, this calculation will be very easy. In other cases, you may have to go with gut feel.
If all three of these items are not favorable, you should stop working on that idea.
If you determine that the need is worth satisfying, you then proceed to decide how to go about satisfying it, which plays into the next decision.
Helpful Techniques
You can use a technique such as the opportunity assessment to guide a conversation with key stakeholders in order to acquire the above information. You may also use a problem statement to answer the first question in the opportunity assessment so that you can more effectively hone in on the actual need. Decision filters are also helpful as a way to filter ideas and see if they are aligned with what your organization is trying to accomplish.
How is a business analyst involved?
As a business analyst you typically elicit and organize information to support this decision. The most effective way to do that is to facilitate a discussion about the need using the techniques mentioned above. You may also find yourself shepherding the idea through the decision making process to make sure there is an explicit decision made whether the need is really worth satisfying.
Create, change, or pass
When your organization determine whether a need is worth satisfying, you then need to decide if you are going to satisfy it, how you’ll organize the work, and what impact that might have on other initiatives already in progress.
Your organization’s decision comes down to three possible approaches:
Create a new initiative to satisfy the need.
This means that your organization need to identify a team (or teams) who will work on that need and figure out where those teams are coming from. This last part is important and often overlooked. If your organization decides to create the new initiative, you also need to determine what team will work on it and decide how you’re going to free them up to allow them to focus. (As opposed to just adding the new initiative to an already overflowing backlog).
Change an existing initiative to satisfy the need.
Your organization may choose to change the parameters of an existing initiative to meet the new need. The upside to this approach is that you don’t have to identify a new teams to focus on that need. The downside is that the original focus of the existing initiative may get lost.
Pass on satisfying the need
The need may be worth satisfying when examined in isolation, but it may not make sense when considered in the grand scheme of what your organization has going on, or you can’t have a team work on that need at the moment without harming the progress of another equally important initiative.
Helpful Techniques
A technique that can be helpful for assessing what teams currently have on their plates and which ones may have capacity is the portfolio alignment wall. This is a way of viewing your organization’s portfolio of active initiatives and the plans for a certain time period into the future. The results of the opportunity assessment as well as considering the current capacity of all your teams will help you determine which route to go with this decision.
How is a business analyst involved?
As a business analyst you typically elicit and organize information to support this decision. It’s likely that if you shepherd consideration of the need, you have the best understanding of the need and how it fits with the skills and experience of the various teams in your organization.
Initiative Horizon
Decisions in the initiative horizon focus on what solution your team uses to satisfy the need and whether it’s worth proceeding once you select that solution.
Notice that your team doesn’t decide on the solution until the initiative horizon because the team responsible for implementing the solution needs to be involved in that decision. You want the people who understand the capabilities of the available technology to be the ones who determine the best way to apply that technology.
The ownership of decisions in this horizon is a bit fuzzier and there may be different people who own different decisions. Ideally you’ll have a person identified (usually a sponsor, product manager, or product owner) who has the primary decision responsibility for the initiative. That person should defer some of the decisions to the more technically experienced members of the team, or at least lean heavily on their input when making decisions. The best course of action is to discuss as a team who will make each of these decisions when you start any new work on your product.
What solution will satisfy the need?
There will be some cases where your team knows the outcome you’re trying to reach but don’t have a clear idea of the best way to satisfy those needs. In those cases, this decision is very relevant.
In other situations, your team has a clear idea of the problem and the solution in which case this decision may already be made for you. If you find yourself in this second situation, make sure you confirm that the solution really is clear and is truly the best one. It doesn’t hurt to take a quick step back to make sure you have a clear understanding of the need and have some definitive evidence that the solution you’re going to implement is the correct one.
Helpful Techniques
A useful technique to identify potential solutions in a way that keeps your focus on the problem to solve is impact mapping. Impact mapping helps you structure a conversation starting with the outcome you seek (stated as a measurable objective) and then work from that to identify people who can impact that outcome, the behaviors you need to change to drive that impact, and the things you can deliver to changes those behaviors and experience that impact. John Cutler suggested five questions that can be very helpful trying to identify and assess the assumptions that are the basis of those solutions.
How is a business analyst involved?
As a business analyst you typically ensure that the there is a clear outcome identified – preferably tied to a measurable objective – and facilitate discussions with the team to identify potential solutions. You’ll also organize the information that results from that conversation and drive toward a decision on the preferred approach.
The most effective way to do that is to facilitate a discussion using a technique such as impact mapping and drive toward a decision.
Build vs Buy?
Once your team has some insight into your preferred solution, you need to decide if you’re going to build it in house or buy it. If the choice is to buy a solution, you need to make sure that you’re selecting something that does not need a great deal of customization, or that you’re willing to adjust your processes such that you don’t need to customize your purchased tool a great deal.
If you can’t find a tool that meets your needs, and you’re unwilling to change your processes to match the available solutions, then you should probably consider the build option if the nature of the activity warrants it.
Helpful Techniques
The purpose based alignment model is a helpful tool to help you make this decision.
When you’re working on solution that supports your organization’s differentiating activity it makes sense to build that solution in house in order to maintain your competitive advantage.
If you are working on a parity activity, a wise course is to see if there is a product in the market that you can purchase and use with a minimal amount of customization.
How is a business analyst involved?
As a business analyst you typically elicit and organize information to support this decision. The most effective way to accomplish that by facilitating a discussion using the purpose based alignment model to identify the activities that you’re supporting with this initiative as well as what quadrant they fit in.
What aspect of the solution (epics) should we deliver and in what order?
Whether your team chooses to purchase a solution or build it in house, you’ll still want to slice that solution into smaller bits to allow you to have short feedback cycles. For the sake of simplicity I’m going to use the term epic to refer to the placeholders for those smaller solution components, as that is the term frequently used to refer to large items on a product backlog.
Yes, I know epic has different meaning depending on what framework you may be happen to use. I’m going with the originally intended definition of epic in software development – a big user story.
With that in mind, this decision comes down to deciding which epics you need to deliver and in what order. What you’re effectively doing here is stocking your backlog.
Helpful Techniques
There are a variety of techniques such as story mapping and process modeling that can help you identify the epics you need to start with. Story mapping can also help you identify the first epics you need to tackle.
How is a business analyst involved?
As a business analyst you typically elicit and organize information to support this decision. If you are fulfilling the product owner role, you are responsible for making the decision regarding what epcis to deliver and their order.
Continue, change, or cancel the initiative
This decision is one your team should make (or revisit, depending on how you look at it) multiple times through the course of the initiative. That’s because you need to make sure you’re incorporating new information that comes in from your delivery activities, as well as factoring in what’s going on with other initiatives in your organization and the impacts of initiatives on each other.
Ultimately, this is a priority decision. What does your organization want it’s focus to be, and where do you want to have apply your teams.
In practice this decision is not nearly as clear cut as it should be. Organizations try to split the difference and avoid the hard change or cancel decisions by having teams focus on multiple initiatives. In this situation they have still made a choice, and it’s not one they intended – none of the initiatives will make satisfactory progress.
Helpful Techniques
To ensure that you have the proper information to make this decision, establish an outcome based metric and review it’s value after every change you make.
How is a business analyst involved?
As a business analyst you typically elicit and organize information to support this decision. You’re also going to find yourself recommending a decision to the ultimate decision maker for the initiative.
Delivery Horizon
Decisions in the delivery horizon focus on those decisions your team needs to make in order to build and deliver the selected solution.
The responsibility for making the decisions in this horizon vary depending on the specific decisions and may fall to a product owner, a technical expert on your team, or you in a business analyst role. I’ve noted more in the description of each decision.
What aspects of the solution should we deliver and in what order?
This is the primary decision your team (generally the product owner) makes on a repeated basis in backlog refinement. You’re determining what user stories are in, which are out, and in what order they’ll be delivered.
Helpful Techniques
There are a variety of techniques that help you determine which user stories should be delivered and in what order. You can refine the epics you identified to determine potential user stories, and then you can use story splitting to further analyze those stories. You may also find it helpful to track your entire backlog refinement process using a discovery board.
How is a business analyst involved?
As a business analyst you typically facilitate the discussion with your team to determine the appropriate order based on implementation concerns and identify aspects of the solution that help you get closer to your desired outcome. You can and should make this decision, especially if you’re fulfilling the product owner role.
How do we build & deliver the solution?
Based on how user stories are described, your team repeatedly makes decisions that determine the best way to implement those stories.
Helpful Techniques
There are numerous techniques that your team can use to determine how to go about building the preferred solution. When exploring these decisions from a business analyst’s’ perspective, I’ve focused on the techniques that are most useful for providing the information the team needs to make those decisions.
In order to make sure your team has the information it needs, you want to describe user stories based on your agreement with your team and according to your definition of ready. The techniques I find most helpful for describing user stories are models, examples, and acceptance criteria.
Example Mapping is a very helpful technique for guiding the conversations you have to identify those models, examples, and acceptance criteria.
How is a business analyst involved?
As a business analyst you typically keep the desired outcome at the forefront of the team and build a shared understanding about the need and selected solution. You do that through properly describing user stories so that your team has the information they need to determine the best way to build and deliver the solution.
Do we have enough to deliver?
Your team should make this decision on a regular basis. It’s how you determine whether you should deploy your most recent work.
You’re trying to determine if the components you’ve built create a viable solution or a viable, workable change to what you already have.
When you make this decision, consider the viability of your changes because you want to introduce changes that are going to work and will contribute toward delivering the outcome you seek.
In some respects, you’re applying acceptance criteria to a group of user stories that represent the solution as a whole.
Helpful Techniques
The techniques that are helpful for making this decision are those that your can can use to determine whether you’ve delivered the user stories as you intended. Techniques that will provide some of that information include a Definition of done, examples and acceptance criteria. You’ll need to supplement that with an assessment of the solution overall.
How is a business analyst involved?
As a business analysts you may be in a position to make this decision, especially if you are also playing product owner role. Even if you don’t have direct responsibility to make the decision, you will most likely play a key role in confirming what was built is viable.
A final note on responsibility
Throughout this discussion I noted in several places the role who is typically responsible for making a given decision. It’s important to realize that these are not hard and fast rules and each situation will be different based on the makeup of your team, your organizational structure, and – let’s face it – politics in your organization.
While I encourage you to use the suggestions in this article as guidelines, you’re best off if you have a discussion with your team and broader product organization to clarify decision responsibilities for your overall portfolio and each individual initiative.
Use the decisions identified here as the starting point for discussions and make sure that everyone involved with an initiative understands who in your case owns each of those decisions. The DACI framework provides a helpful way to structure your conversations.