If you’ve not seen my announcement on LinkedIn, I have been very busy developing a course called Preparing for the Agile Analysis Certification Exam. It has been published on the Udemy platform, so it is available to everyone. This is a self-paced version of the course I have taught to Business Analysts across the US in association with the Bluegrass chapter of IIBA.
This covers the entirety of the Agile Extension to the BABOK Guide with over 3-1/2 hours of videos and several quizzes. The quizzes are intended to help foster the “Agile Mindset” and help you grow in understanding of the concepts presented in the Agile Extension.
If you are interested in learning more about Agile, becoming certified as an Agile Analyst, are curious about whether there is a career path for Agile Analysts, or just need some ideas on how to improve your projects – this is a great course to cover everything.
Visioning is used to determine the desired outcome for an initiative worded in a concise and approachable manner.
Agile Extension to the BABOK® Guide – section 7.24
When Patriots coach Bill Belichek meets with his team to begin practices, I would imagine that the first thing he says is something like “Our goal for this season is to win the Super Bowl.”
Everything else the team does is derived from that goal. The team may not fully know how they are going to do that. And certainly the other teams want to prevent them. But everyone on the team knows that when Coach says “We’re going to win the Super Bowl” he knows they can succeed. And they understand what winning means.
Elements of Visioning
But there’s more to Visioning than simple inspiration. Yes, it is a set of beliefs. But it also is a SHARED set of beliefs. Everyone gets there or no one does. That is called a Vision Statement
This shared set of beliefs comes out of facilitated vision exercises – or Vision Exercises. Finally it is expressed in detailed objectives to measure the goals – known as Impact Metrics. These metrics show that the plan is working, but are not necessarily cause and effect related.
Back to Football, Coach may set goals for player’s strength, speed and skill. Will those cause them to win? No. Will they help? Yes. That’s the difference between correlation and causation.
Visioning begins in the Strategy Horizon, where the organization determines which initiatives align to organizational goals. The vision for an initiative is set just before the beginning of the project and lasts through it’s duration.
The Vision Statement helps orient all those involved in the project toward the overall goal both of the initiative and the organization. It identifies how the resulting product will leave an identifiable mark on the products or services provided or on the organization as a whole.
One additional consideration is that Visioning may be associated with multiple related initiatives.
Finally the context is communication, and the audience is internal teams and external stakeholders.
In Agile, many techniques can be used to improve different aspects of the processes. Many of them may on the surface appear to be similar in purpose. But when you look closer, there may be a distinction that favors one over another for specific situations.
So, how do we determine which technique is appropriate to address the specific issues we are seeing?
When deciding which technique to use, the three factors I look at are the Horizon, the Audience, and the Context.
In other articles, I’ve talked about the Three Horizons – Strategy, Initiative, and Delivery. Understanding which Horizon we are dealing with impacts which set of techniques is available.
Some of the usefulness of some techniques spans across all Horizons. Others may be in two or only one. Appropriate understanding requires understanding the purpose of each Horizon, remembering that a Horizon is not so much a time frame as it is a level of decision making. Decisions can impact an initiative from any of the Horizons.
For example, if a project is actively being developed, the Strategy Horizon can realize there needs to be a change in direction. Just because we are actively delivering the product does not mean Strategy has ended. In Agile, all three Horizons can be active simultaneously.
And that feedback can go both up and down through the Horizons. So understanding which techniques are appropriate to each decision-making level – to each Horizon – is essential.
Below are 4 charts which identify the various techniques as well as which source they are discussed – the Agile Extension or the BABOK Guide
Next is the Audience. Answering the question of “Who,” the Audience can be condensed into two broad groups:
Part of the team
External to the team
So, Who is the Team?
In Agile, the team is considered to be those involved in identifying and delivering a solution to a problem. The team may be further broken down to those working at a specific Horizon – for example, those working with organizational strategy are part of the team, but they are not delivering the product. One would be the Strategy Team, the other the Delivery Team. But for our purposes, that distinction is covered when you consider the Horizon in choosing a technique.
Those that are external to the team is everyone else. External to the team can include individuals such as Customers, Subject Matter Experts, Vendors, Regulators. These would be anyone who is both interested in the success of an initiative, but not involved in bringing the project to life. And they may or may not be part of the organization.
Now we are getting to the heart of the matter – why do we need this technique. Context is another way of asking, “What is the purpose?” or “What do I hope to achieve?” It is the “Why” of the decision process.
There are five categories of Context.
Product Management or Refinement
Understanding Your Customer
So let’s look at each of these.
Techniques that fall into the Communication context when, not surprisingly, the point is to communicate information. The receiver of the communication is determined by the Audience, which I mentioned above.
Some examples of Communication techniques would be things like Planning Workshops, Portfolio Kanban, Visioning, Retrospectives, Backlog Refinement, and Reviews.
Process Analysis involves looking for ways to improve processes. This may be processes involving the team, or in the solution itself.
For example, a Process Analysis may find gaps in the solution.
Another example, Process Analysis may reveal that the team is getting bogged down at a certain point in delivery. Perhaps the team needs to adjust to prevent that from continuing.
Some examples of techniques useful for Process Analysis include Value Stream Mapping and Impact Mapping.
Product Management or Refinement
Here we are concerned with delivery schedules or other items associated with defining the product. These answer questions like:
What is necessary?
When do we make a decision?
How does this align with our objectives?
When will features be delivered?
Examples include Minimal Viable Product, Product Roadmap, Purpose Alignment Model, Real Options, and Kano Analysis.
For Requirements Management, the concern isn’t the requirements themselves so much as how they are collected, sequenced, reviewed, prioritized, or refined. For analysts involved in Agile, this can be a large portion of the work.
Several examples of this context include Relative Estimation, User Stories, Job Stories, Spikes, Story Elaboration, Story Decomposition, Story Mapping, and Behavior Driven Development.
Understanding Your Customer
The context of Understanding Your Customer involves techniques in which details about the usage or motivations can be conveyed to the team. Many times, understanding the motivations can have an impact on the final design.
Some examples include Personas, Storyboarding and Value Modelling.
Coming into Delivery, the Strategy
has identified a need to be met, and the Initiative Horizon has identified a
solution and its features. When working as an Analyst in the Delivery horizon,
the key is to expend the least effort to discover information and support
informed decisions about the solution.
I’m sure you realize it is not easy.
It requires a great understanding of what information is useful for decisions
on the solution, as well as how to find quickly, and present it in a timely,
Someone introduced me to the concept
of “Planned Spontaneity” That is where the person has things set up so
that if they want to go on various kinds of excursions, they always have bags
and supplies packed and ready to go. It takes a lot of planning to be
spontaneous. Or, as Rod Stewart used to sing, “Her adlibbed lines were well-rehearsed.”
So when this “Challenge” involves the least amount of effort, I think that also consists of a lot of planning to make it happen, so that the work at the time it’s needed is minimal. To do this, the Delivery horizon addresses two questions. First, looking at the unfinished but defined backlog, the Analyst asks what has the highest value. Then the delivery team asks how to deliver value most efficiently, with the least waste.
A Ready Backlog
In the Agile Extension, there is a
discussion of how to know when a requirement is ready, as well as when do you
need to have it available. On the first of these questions, the Extension
talks about “Invest” criteria. For now, we’ll say Invest stands for
“Independent, Negotiable, Valuable, Estimable, Sized Appropriately and
Testable.” I intend to get to the techniques later and will elaborate more at
Whether you are talking about User
Stories or other formats for requirements documentation, the INVEST criteria
work well. The point is that the requirement is well constructed with
Clear and Concise acceptance criteria and is achievable and Desired as shown in
For the second question, sometimes
the requirements should wait and be ready in the near future. Agile suggests
having things prepared for near term development. If something has to wait,
then having it ready now is wasted effort, which takes away from the closer
Additionally, some frameworks offer suggestions for how far ahead to finalize requirements, so that you don’t rewrite the requirements as better understanding surfaces.
Prioritization and Sequencing
The next element of the Delivery Horizon is Maintaining the Backlog. Here we work with the Product Owner to Set priority and sequence to deliver value quickly. The purpose is to support near term development, and the outputs are decomposed features and refined requirements.
The Agile Analyst’s efforts prevent
obstacles in several different ways, such as facilitating a better
understanding of dependencies, coordinating efforts with other groups, and
How do Analysts remove Roadblocks?
This question requires an
understanding of the Analyst’s role versus other leadership roles on the team.
Then, within the Analyst role, what are the roadblocks that can occur.
The first one is a lack of
understanding. If the team does not understand, it will cause churn or will
prevent the story from being worked.
Another is the interrelationship
between features internal to the solution. Without these
interrelationships being understood so that proper sequencing can occur, you
may be trying to develop against something that doesn’t exist. So when
it’s delivered, there’s no way to know if it works. Remember, we’re
delivering working software.
Another is external dependencies,
which are much like what was just discussed.
Ensure Learning Happens
Next, there is Ensuring Learning
Happens in the Agile Context, and in this, we first are talking about
Processes. By Processes, we are talking about how the team works, not how
the process works, or the stakeholders will use whatever is being
The team is observing how well they
are working, and can they work better. These observations include
feedback to the Initiative or Strategy Horizons because they need to know how
to help Delivery better.
The other learning involves the product itself. Constant feedback determines whether the value is being delivered and the expected results met. This feedback may affect prioritization and also other horizons. Here is one of the distinctions between Agile and Waterfall – that feedback from Delivery can affect the other horizons. Waterfall would say, Delivery is the result of planning, so there’s nothing that goes back in time to fix what has been done. Perhaps that’s a bit oversimplified. The Agile Mindset recognizes this project is not performed in a vacuum. The speed of delivery affects resource availability for other initiatives and other needs.
Focus on Vision and Value
Finally, there is Maintaining Focus on the Product Vision, Customer, and Value. The Agile Analyst’s work continually promotes a shared understanding of how the work achieves the vision. Focusing on value means the most valuable things are prioritized and delivered early.
From the Strategy Horizon, we understand the overall purpose of an initiative and its intended impact. But there is a lot that remains undetermined at this point. The initiative may have the organization’s backing, but that doesn’t define exactly how it will work, what resources are involved, or how much it will cost. The role of the Initiative Horizon is to fill in those gaps, report back to the Strategy Horizon for decisions to continue or end research, and potentially provide the requirements to the Delivery Horizon.
So, look at this in more depth.
Identify Solution Options
One of the primary functions of the Initiative Horizon is to identify options that can potentially meet the organizational need determined by the Strategy Horizon. Implied in this is that there are options – more than one – which have that potential.
In determining these options, a clear understanding of the Strategy Horizon’s intended purpose will have to be established. If that has not happened, the analyst will gain clarification from the decision-makers in the Strategy Horizon. To eventually bring the desired results, clear and measurable objectives are communicated and evaluated here.
We need to consider “what is the shared understanding?” and “what are we assuming?” For example, one assumption may be that there is an affordable, workable solution. The analyst will need to discover if those assumptions are correct or not. If not, then that option will cease to be considered, and that result communicated to decision-makers in the Strategy Horizon.
Other considerations include “What could cause the project to fail, a delay, or a limited function?” To address this, the analyst needs to understand from a high level, what this optional solution does, and what constraints would make it not a viable solution. For example, a vendor product may meet the need, but it may not work in our environment.
Another element of the Initiative Horizon is identifying the components needed by the stakeholders and collecting information about its effect on the need, costs, and constraints. Collect enough detail to make informed decisions without wasting effort by going too deep.
The components are something that is reviewed and revised periodically though the duration of the initiative. Also, the components may be identified for all of the options, not just the one eventually chosen. This is because part of the decision will involve which features are included and how much effort those features require.
Size of Items
To determine the size of the items requires that the components are identified. These will often be referred to as Features. Each component needs an approximate size reflecting the expected work effort involved. At this point, it is a very high-level estimate.
Agile Extension to the BABOK® Guide – section 5.3.5
With those components identified, we need to determine the priorities and sequence components. This will be revisited often and influenced by feedback both from Delivery and Strategy
Prioritization can be impacted by several factors, such as the impact of the feature, cost, how the project is progressing, multiple levels of feedback, and others.
Features may be prioritized for options before a specific solution is chosen because the scheduling of resources required to bring prospects to reality will need to be discussed. Schedule constraints could tip the scales of one option over another.
In recommending an option, a simple way of looking at it is, “Which option gives the most for the least and still meets the need and constraints?” To decide that, we don’t need to know everything, but we need to know enough. And since we’re evaluating multiple options, we need to be consistent in what we use to make the decision.
To make the recommendation, confirm that our assumptions are valid. These could be organizational assumptions or assumptions about a 3rd party entity or product. We will need to see:
How difficult is it to do what this option requires to get it live.
Are the impacts on the organization, either intended or not intended?
How well does it meet the need?
How high of a price?
Determine When Need is Met
The role of the Initiative horizon does not stop at determining a solution. It continues while the product is being delivered to determine when the need has been met. Again though, this is based on analysis, which leads to a recommendation. The ultimate decision does not belong to the analyst, but a responsible decision-maker or decision body.
Each delivered feature is an opportunity to determine if the need is met if more is required if changes are needed or the project canceled. The intent is to avoid waste by only satisfying the need identified by the Strategy Horizon.
Along with determining when the initiative has met the need, a counter analysis also continues concerning the initiative’s ongoing viability. By viability, that not only means whether to continue the initiative, but also whether it needs to be altered in some way.
Agile is called agile for a reason – because it is built to handle change. So we have three options: to Continue, Change, or Cancel the initiative. The basis of that assessment is several factors that constantly change, such as the realized impact, success measures or KPIs, remaining work, constraints, feedback from delivery, and strategy.
When we think of Agile, we often think of solution delivery.
One of the things I’ve observed about IIBA is that it looks beyond the boundaries of the delivery functions. The Business Analysis certifications look before and after the project, to identify activities leading to and resulting from the project.
Agile Analysis is no different. Here, we are looking at what goes on from the very beginning of an idea, through to its delivery. So, IIBA has identified three horizons – Strategy, Initiative, and Delivery.
The three horizons allow the organization to have a framework for response.
Having multiple horizons identifies the stages and shifts in focus that occur as an initiative matures.
To explore the interplay between each Horizon and how they inform each other.
To understand a fuller impact on the organization. This gets into why we are doing things in the first place, instead of merely what are we doing.
The Strategy Horizon takes the broadest view possible, looking at the organization as a whole. Decisions made here support organizational strategy and resource allocation. We are identifying opportunities such as products, services or initiatives, or areas of risk and ways to mitigate against those risks.
Risk at the strategy level is different than at delivery. Here we are thinking of risk to the organization, not the project. These risks can include:
Competitive Landscape changes
Disruptive business models that undercut your revenue stream
Public Relations issues
At the Strategy level, we are concerned with the overall organizational strategy. With that kind of a view, a strategy is never talking about the immediate term. It takes time to analyze, theorize, confirm, and set a vision for an initiative. Add to that the time to deliver it.
Moving on to the Initiative Horizon, here we become more focused on a goal, initiative, or a team.
So, when I look at this impacts list, and I see a goal vs. an initiative, there’s a distinction. At this time, the purpose has likely been identified, but the means to achieve it has not. So, there needs to be a decision process to determine the solution. That solution becomes an initiative and is further refined until a decision is made to deliver it.
Just because something is in the Initiative Horizon does not mean there is ever an intent to act on it. The same can be said about strategy. But it is a preparation and exploration horizon.
Initiative based decisions include:
Identifying how to meet a goal, which becomes an initiative
What is desired for that initiative
Identifying needs and options
Inform both the Strategy and Delivery Horizons
Decisions made here affect the delivery of a solution and support the delivery time and product.
Identifies the work breakdown, delivery, test and prioritization
Focuses on the needs of the stakeholder
3 Planning Horizon
The point of these Horizons is that they are not purely phases or stages. An initiative is not necessarily in one to the exclusion of the others. Instead, influence is bounced between the Horizon as feedback and knowledge are continually gained.
A clearer picture is illustrated below.
As you can see, information is bi-directional. Agile brings news back to the decision-makers from the delivery team. The information exchanged between each Horizon informs the decisions made at the receiving Horizon.
With this level of exchange, the organization goes beyond delivering a solution, to practicing Agility – the application of an Agile Mindset across the organization.
In today’s post, I will discuss The Agile Mindset.
You may be thinking, why do they call this a mindset? Isn’t it simply a methodology or framework that is applied to solve a problem? Some clarity is needed to define what is a framework or a methodology. And with that clarity, we will show that Agile is neither.
So, let’s start by thinking about what a methodology is, versus a mindset.
Why a Mindset?
On a high level, a Mindset is a way of thinking about things. It involves ideas and attitudes and is based on principles. In Agile, there are seven principles, which we’ve touched on already here. Agile can be applied using any number of methodologies or frameworks, so long as those principles apply.
Agile is not a framework. Instead, you can think of it as a collection of frameworks that meet a mindset, possibly including frameworks that have yet to be envisioned.
To be Agile implies that there is flexibility for each unique situation, allowing the practitioners and teams discretion to choose what works. Each project is unique, and by selecting an appropriate implementation of a framework – a methodology – that uniqueness is encouraged.
Mindset – Framework – Methodology
Let’s clarify this a little more. I find it is always useful to give a simple definition.
The difference is from general to specific. To start, a Mindset is simply a way of thinking about work. It is a philosophy which shapes decision-making, upon which a value system can be determined.
A framework is a set of concepts and ideas that guide teams. This goes beyond philosophy to defining broad techniques which may be used to define and address the problem.
Finally, a methodology is a specific application of a Framework.
So, if you are working in Strategy, and the organization decides a project needs to use Scrum, that is a Framework decision. However, if it is later determined that the sprints will be three weeks, and that specific elicitation techniques will be used, such as Job Stories instead of User stories, that is defining the methodology.
Applying the Agile Mindset
When applying the Agile Mindset, we need to understand a few
One of the misconceptions about Agile and it’s related frameworks, as well as any other project methodology, is that it’s not limited to Information Technology. Agile has been applied to Manufacturing, Retail, Legal, Medical and many other organizational domains.
It is dependent on a few things such as Collaboration, Skill and Knowledge. I think of these as Risk Factors. If these are delayed or ineffective, the results will be sub-par. What jumps out to me on this level is Knowledge because that is something that becomes available just as it is needed, as User Stories or Cards are “groomed.” It also can be viewed as an output or by-product of Collaboration and Skill.
When Agile is applied, value is delivered based on needs, with an iterative delivery, with known expectations on what is delivered, how it will operate and when it will be ready.
The 7 Principles of Agile Business Analysis describe how Agile operates. But there’s another way to look at it. When you see an Agile environment, what are the characteristics of that environment? How can you look in from the outside and say, “That looks like they’re doing some flavor of Agile?”
Examples of Agile Frameworks
Because of the dominance of Scrum, I often hear the terms Agile and Scrum used as if they are the same thing. Agile is not the same as Scrum. It is not a single framework. It is not prescriptive the way a framework is. An organization could apply any framework, such as Lean, Rational, Six Sigma, and of course Scrum, and would still be Agile. Also, some of those frameworks tend to focus on the development horizon only. Agile, as we’ve already discussed here, can be applied well before development.
First, there’s an emphasis on respecting all of the team members and their creativity.
You can see that feedback and learning is greatly valued to guide the delivery of the highest-valued work first.
Collaboration and communication is a core priority, not just on the team, but all stakeholders, to have a shared understanding.
Work is divided into small chunks. Working, functional outputs are delivered on a regular iterative schedule.
When you look at the list of Agile frameworks from above, and I claim that as a representative but not an exhaustive list, each of them demonstrates the four characteristics.
According to legend, 17 people went to Snowbird Ski Resort in Utah in February 2001, desiring to codify a document uniting their various methodologies. What they came up with was the Agile Manifesto.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Three sentences and four bullet points upon which countless volumes have been written. Why is it that something so simple has become so transformative?
Let’s answer that question from the inside out. The first thing is those “bullet points,” or four “comparisons” have turned upside down the value system of previous problem-solving philosophies.
Previous to the methodologies which make up Agile, the focus was process and tool-centric. The problem is, it made people adjust to tools instead of having tools serving people. Agile puts people ahead of tools.
Next the Manifesto talks about how it is more importing to have things that work instead of comprehensive documentation. That is not to say that documentation is unimportant. Instead, the implication is to avoid documentation that looks so far ahead that the finished product doesn’t match. In other words, it is better to document what works than what you think will work.Don’t document yourself into a corner.
The third “comparison” is my favorite because it talks about finding out what is needed instead of reading a legal document. The contract would not exist without the customer, and most likely, the customer is not the legal department (unless it’s a law firm). Customer needs are seldom adequately documented through a contract. So, when meeting the need, look at the customer instead of the contract.
The final comparison is also often confused. Change is the plan in Agile. It is a recognition that things change midstream. And if the plan is set in stone before the work begins, the product may be inadequate before it is implemented.
The opening statement, “…uncovering better ways … by doing it and helping others to do it” brings up some broader perspectives. The first is the value of experimentation and empirical analysis. Some of the things brought out may be addressed multiple ways. The goal is to find the best of many ways to solve the problem.
Once we find the best way, be willing to share the knowledge so that other projects benefit from what is learned. In other words, let the feedback influence the decisions. A decision is not final until it is. Or stated a bit more academically, each item in the plan becomes a hypothesis to be proven, again and again, until that item is delivered.
If you’ve followed my blogs, you’ll know that I love to explore things that appear to be simple, but the impact is profound. That is one of the reasons Agile is appealing to me. No matter how much I understand, there are always new lessons to learn, and ways to overcome problems.
And it’s not just for software since Snowbird in 2001. Here is an article by Matt Hilbert published on Red Gate Software. The article traces Agile principles to the manufacturing of WWII fighter jets and the beginning of the Skunk Works.
There are multiple ways you can look at planning, and each may apply to each Horizon. Here are a few that have been applied over the years. I’m sure there are others.
First, there’s Iterative Planning. Any discussion about Agile has to mention Iterations as part of its structure. And in planning, it’s no different. On a recurring basis, the Agile Business Analyst reviews, refines, and prioritizes the work based on the latest insights.
Then there’s Adaptive Planning. The very word “Agile” implies change or flexibility. Priorities change. Needs change. So we have to Adapt. Agile will continuously be looking at what is going to deliver the highest value and striving to work on that next.
Then there’s the combination of Both. In this type, Iterative and Adaptive planning are combined. Priorities are repeatedly set, based on the latest available information.
So, How do we know what is the Priority? How do we know what to Adapt? The answer is, “Feedback.”
To get feedback, the Agile Business Analyst forms communication between a lot of different folks within or external to the organization.
Identify the customer. Most often, of course, this is the primary individual or group who needs to be consulted. They may be internal – associated with some support process within the organization. Or External, classically represented in retail as the buyer of a product. It may be a group too broad to handle, especially for retail. This is often performed by a lead person or a group that serves as the voice of the customer.
The Analyst may observe or get information from sources, some of which might not be included in the organization chart, such as Competitors. These may be hostile witnesses, as they don’t want to give up a competitive advantage. But there are ways to know what a competitor is doing. In retail, all you have to do is walk into their store. Or maybe read their Advertisements.
Partners are groups that, for one reason or another, are on your side. Because they deal with things that your organization may not directly see, they can be a great source of information that can inform some of your initiatives.
Investors are often self-appointed experts. They can be for you, or they can turn against you. Managing their expectations in specific environments can be the difference between the success and failure of the initiatives.
Subject Matter Experts are your internal sources. These should know the issues better than anyone. It is essential to see them embracing the changes, as often they are the customer. Other times, they are responsible for some of the technical requirements necessary for success.
Regulators, or the legal environment, is often the motivation for change. They may force an artificial priority. For example, if the IRS comes up with some new regulations concerning one of your company’s business practices, it becomes crucial to meet those demands. Your Board does not want the embarrassment of an IRS adverse finding.
Agile Analyst Activities
So, looking at a High level, how can you group the functions that an
Agile Business Analyst performs?
Linking of Strategy to Initiatives to Resources
Elicitation – discovering, communicating (two-way), and interpreting the findings.
Clarifying – ensuring that the understanding of the Analyst is correct. Communicating who this is for, who this is by, and determining impact.
Helps Decide – priority of initiatives, features, and development work Items. Also, help decide approaches and providing information on trade-offs from one path to another.
This page may contain affiliate links. I may receive commissions for purchases made through links on this page.