Category: Blog

Letting Go

Letting Go

During the last week, it seems that everywhere I go, I am running into a constant theme. People around me are letting go. And letting go is one of the most challenging things we do as humans.

My family is in the process of decluttering over a decade’s worth of stuff, and I see first hand how some of these items evoke strong emotions. Take the exersaucer, for example, that was used by my daughter, who is now 5ft 9in. As wonderful as that time in our lives was, we can never return to it. The stations on each side are housed in a white plastic casing that now has changed colors to a light tan.

I jokingly asked Lily if she wanted to give it one last turn. Of course, I got the response, “Dad, that sounds pretty shady to me.” That is her way of saying, stop with the Dad jokes.

It’s not just my household, though. My Mother has the loss of her furry companion; a Yorkie named King who passed at the age of 84 in dog years, 12 in actual years.

And there have been others I’ve helped within the last week, too.

I’ve learned that the challenge of letting go involves some level of the grieving process. It doesn’t matter if the letting go is from a tragic loss, or just from the passage of time and how life causes transitions, grief is often involved, though we may downplay its significance.

Life’s Transitions

So how do we make the transition?

If that question is asked too soon, it can be jarring. The stages of grief should not be circumvented for significant life events. And each stage likes to return to visit us often.

So, I will ask the question again, with that as a caveat. Knowing that change often invokes grief, how do we make the transition?

First, we need to see if we are ready to make the transition. If we are not ready for the transition, we will never accept it. And acceptance is vital because we often need to take action over and over again for a change to take hold.

In my decluttering example, it isn’t just the exersaucer that we need to let go. It’s clothing, bedding, toys, artwork, crafts, and a thousand other items. And it’s not just things involving my daughter.

For me, it’s books. Many of which I intended to read but never did. And now that season of my life when I should have read them is past. They are no longer relevant or timely. As I’ve gone through boxes of stuff that have not been opened since our last move 7 years ago, it is surprising how many books I have that I don’t even recognize, and many must have been from before we married. A good portion of which are of the self-help variety – so much that one visitor looked at my shelves and asked, “What’s wrong with you?”

My reply, “You mean you can’t tell?” Followed by a psychotic laugh, just to see the effect.

One of the books I found was “Who Moved My Cheese,” which is a book that is about … you guessed it … Letting Go. Can you guess what I did with that book?

Yep, it’s been donated.

For my wife, it’s things she remembers from shopping experiences with our daughter. Every so often, I hear the exclamation, “Lily! You’ll never guess what I found. Do you remember…?” Then she tells a story about something she hasn’t seen in years, and suddenly we must keep it.

This makes little sense to my logical mind. But I conclude that Marie Kondo doesn’t work when everything “Sparks Joy.” That and the books explains our storage unit.

Still, no matter what the circumstances, letting go is a necessity. Our ability to let go is directly related to our ability to excel in life. Why? Because letting go of the past is necessary for us to envision a future.

And for myself, letting go involves more than just clutter. Every so often, it is important to take a risk, to change course. And this pandemic seems like the natural time to do that.

The Point

As Business Analysts, we often speak of techniques and skill-sets involved to identify process gaps, requirements management, and the like. There is another part of the job that requires empathy, and empathy is a core part of leadership.

Whether it is letting go of the clutter in our lives, painful events, or letting go of what we have done to move toward a better future, letting go is difficult.

As a business analyst, one of my roles is as an “agent of change.” That means some people love seeing me come because they know things will get better. But others are not ready for change. They don’t see the vision or don’t like the vision they see. For these situations, often reminding of the drawbacks of staying put can help soften the resistance.

But no matter where someone is on willingness to let go, it can always be said that letting go is a necessity for moving ahead. And my job is not just to gather requirements on a product vision; it is to create as smooth a transition as possible. The emotional intelligence of handling change is a huge part of getting a project done.

My job is to help them

It may mean that the vision gets adjusted to embrace the concerns of a group that was overlooked. Great – I’ll pass these changes along and get approval.

It may mean that I need to help people see a vision other than what they know. That’s great too. I can help lower the level of fear involved with change by highlighting the benefits, not only to the organization but to the individuals affected.

What do I do to help? The main thing is to listen. Once the problem is voiced, the fear of it lessens.

I’m very thankful for this past week because it reminds me again just how important it is to help people move toward what is next.

And the real reason I have all those self-help books that I mentioned earlier is because in reality they are more useful professionally than many people realize.

Three Factors in Choosing the Best Technique

Three Factors in Choosing the Best Technique

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

Techniques for the Strategy Horizon
Techniques for the Initiative Horizon
Techniques for the Delivery Horizon
General Agile Techniques


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.

  • Communication
  • Process Analysis
  • Product Management or Refinement
  • Requirements Management
  • 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

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.

Requirements Management

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.

How to Avoid Delegation Through Abdication

How to Avoid Delegation Through Abdication

As I am writing this, I have recently finished a panel discussion on Agile Transformation given at my IIBA Chapter. One of the recurring themes of any discussion involving Business Analysis is stakeholder engagement. Lack of stakeholder engagement shows up in a myriad of ways ranging from indifferent behaviors to actual hostility toward anything involving an initiative. It is almost impossible to discuss without this subject surfacing.

One of the most common forms in which stakeholders are not engaged can is Delegation Through Abdication. To give credit where it is due, I am borrowing this term from Larry Hagner, who writes a blog called The Good Dad Project. I think it originated with The E Myth Revisited, by Michael Gerber.

Delegation Thru Abdication occurs when you feel overwhelmed by a subject and want to avoid it in any way possible. Perhaps you’ve been burned in some way. Or you have no vision for it. So you hand it off to someone else. Someone who really should not be responsible for the decisions, or should not be solely responsible for it. So you send representatives to do your job.

Does this sound familiar?

The problem doesn’t go away. If anything, it usually gets worse because, although the delegate may end up handling things wonderfully, the more common scenario is that they don’t. And even if they do knock it out of the park, there’s still the emotional side. You know you’ve compromised. They know you’ve compromised. They’ve lost respect for you. And you’ve lost respect for yourself.

One of the things I’ve learned in Business Analysis is that you cannot make anyone do anything they don’t want to do. The motivation must be within them to do it. But we can encourage that motivation to the surface and grow in strength.

I mentioned motivation, and that is what we need to explore. What causes the behavior? Why does this person want to avoid it?

I have often said when giving talks or teaching that Business Analysis does involve a fair amount of psychology to understand the motivations of stakeholders and help them understand their fears. Those fears represent concerns that need addressing as the project unfolds.

I find that merely asking the question “Why” often opens up the conversation to valuable input for the project. This happens in 2 ways.

The first way is to identify whether the fear is realistic or not. There’s no telling how much we worry about things that will never happen. So having someone with some objectivity to look at the concern and evaluate it can be helpful to let the person go past the fears.

The second way is through mitigation. And this truly is the point of this article in the first place – because someone was abdicating their decisions to someone else, requirements are missed. That creates a self-fulfilling prophesy – “I told you it would never work.”

Of course it doesn’t. Absence sabotaged it.

As Business Analysts, we see that stakeholder engagement is one of the most significant risk factors in project success. I believe it is as essential as the quality of the delivery team. Without that engagement, people will not be able to determine what is needed.

Whether these concerns are realistic or not, they are addressed initially by identifying them. As the saying goes, “A problem identified is half-solved.” The answer can only come once the question is asked.

So, if you want to avoid Delegation Through Abdication, start by asking, “Why do you want someone else to represent your interest?”

The Three Horizons

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.

Strategy Horizon

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:

  • Regulatory Changes
  • 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.

Initiative Horizon

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

Delivery Horizon

Decisions made here affect the delivery of a solution and support the delivery time and product.

Delivery also:

  • 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.

Agile Extension to the BABOK®  Guide – section 3.2

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.

Process Begins with Bach

J.S. Bach

Yes, that Bach. Johann Sebastian. There were others, his children primarily. In many ways, western music is influenced by him more than anyone else in history, including (I can hear the collective gasp) the Beatles.

I’m not going to review his impact on music though, but his impact on the beginnings of my IT career.

What does Bach have to do with “process”

In college, I was a double major in Applied Mathematics and Music. The Music major was much the harder of the two. And Dr. Hall was the most challenging professor of all. I will admit to never getting over a C+ in any of her required classes. Although I liked her as a professor, I thankfully only had her for two courses needed for my major.

It was Spring term of my senior year when I took Baroque music history, a requirement for the major. And the most significant figure of that period was, of course, Bach. And as usual, my research papers were insufficient to get a B, but I did improve significantly by changing my approach to the material.

Instead of reading tons of materials from various musicologist (the term that is given to music historians), only to choose the wrong sources, I did my own thing. I dissected one of his works, “The Easter Oratorio.” And by dissection, I mean the basis of my paper was a discussion of a chart I constructed which looks more like a Work Breakdown Structure than it does a piece of music. That brilliant shift got me up to an impressive C+ in her course.

By the way, my overall GPA was 3.3. And I was the highest-ranking music major in my graduating class. Well, I was the only music major in my graduating class. It was a small school.

The Discovery

The approach I took toward this paper is one that dovetails nicely into my eventual profession in Information Technology. I’m not going to rehash the paper but will show several of the elements Bach commonly used. By identifying all of the source material used in the piece, I was able to document the musical equivalent of a transformation process, both on a thematic and structural level.

That transformation is illustrated in various ways. Thematic transformation can be analogous to data transformation in systems. When looking at thematic transformations, you can see where the themes started and how they were changed along the way to a finished product. Common transformation processes include truncation, key changes, inversion (the theme basically upside down), retrograde (backward), and various repetitions with other themes creating a counterpoint or counter melody.

But another discovery is the structural transformation, which is more in line with process analysis. Bach is notorious for structural frameworks. Often involving numerological symbolism, these structures are part of the story of each composition.

Later generations would settle on the simple ABA “song” or “sonata” form. Often Bach would use a ABACADACABA form. Yes, that is exponentially more complex. Although this work is considered short, lasting about 45 minutes, each of those sections did have some time to develop. All those “A” sections are repetitive in style, not content. In his compositions, the central “D” section would be the point of highest tension. This is called a chiastic structure, which Bach used as symbolic of the cross, which is the subject of Easter.

Often the central section would feature intervals of an augmented 4th, called “the devil in music” partly because of its extreme dissonance, and partly because of its difficulty to sing that interval. In the Easter Oratorio, he did something different. He changed keys, adding a sharp to the key signature. That sharp also symbolically represents the cross.

The musical themes, the lyrics, and the structure of the piece all tell the story.

Relation to Information Technology

With the thematic and the structural transformations, Bach addresses the subject in both a personal and an overarching global sense. I find that mirrors much of what we do with systems.

In the same way, as a Business Analyst, I use tools and techniques to communicate the desired transformation. We transform individual elements through data manipulations and global structural elements through process redesign. This transformation is of processes and data. The tools I use augment the desired changes, highlighting specific functionalities. They break down the elements of a feature the same way Bach segments his themes. They move to the critical point of decision in a way similar to how the conflict redeems the theme and propels it to its final destination.

I would not realize how important this paper, and a couple of others, would be to my eventual career. I got started in IT because of my Math degree. But I understood it so much more because of my Music major.

While cleaning out a storage unit, I found my old Music History folders. And there it was. The orange notebook I used for the Baroque Music History class. And inside was the paper called “The Symbolism, Form, and Rhetoric of the Easter Oratorio by J. S. Bach.”

As I reviewed this paper, I was reminded that there is a language the composer used to tell a story — the techniques used in the composition highlight the transformations. And like Bach, I have a language, a set of tools, which I use to tell a story of transformation.

Additionally, I saw how it mirrors communications among multiple stakeholder groups. If A were the shared understanding, the other sections are enhancements from other groups. As a CBAP, I have experienced enough to communicate on multiple levels. It is the difference between ABA and ABACADACABA forms.

Understanding the Agile Mindset

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 Extension to the BABOK®  Guide – chapter 2.2

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.

Mindset – Framework – Methodology

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 things. 

Agile Extension to the BABOK®  Guide – 2.3 Applying the Agile Mindset

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.

Examples of Agile Frameworks

Characteristics of Agile Frameworks

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

Various 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.

Characteristics of Agile Frameworks
Agile Extension to the BABOK®  Guide – chapter 2.2
  • 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.

Agile, Shmagile – What’s so Great About the Agile Manifesto?

Agile, Shmagile – What’s so Great About the Agile Manifesto?

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.

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.

Agile Alliance


Three sentences and four bullet points upon which countless volumes have been written. Why is it that something so simple has become so transformative?

Clarifies Priorities

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 important 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.

Broader Picture

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.

Role of Agile Analysis


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.

Types of Planning
Agile Extension to the BABOK®  Guide – pg. 3

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.

Sources of Feedback
Agile Extension to the BABOK®  Guide – pg. 3

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?

Activities Enabled by Agile Business Analysis
Agile Extension to the BABOK®  Guide – pg. 4
  • 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.

What is Agile Analysis?

Agile Business Analysis begins with a basic concept of the simple feedback loop shown here. No matter what flavor of Agile you are using, everything you do in Agile can be boiled down to an application of this feedback loop.

Inspecting and Adapting

Feedback Loop
Agile Extension to the BABOK®  Guide – pg. 3

In Agile, you are either inspecting or adapting. Either you are gathering information based on data, interviews, research, or other sources, or you are taking the information and determining what to do about it. This simple feedback loop is applied to all levels of planning in the organization.

Planning Horizons

When we talk about levels of planning – that is what the Agile Extension® calls a Horizon. IIBA breaks it down into 3 Horizons

Three Planning Horizons
Agile Extension to the BABOK®  Guide – pg. 3
  • Strategy – Looking long-range to determine opportunities and risks and come up with potential needs or opportunities.
  • Initiative – Reviewing the opportunities and needs identified by Strategy, and determining a broad approach to meet that challenge
  • Delivery – Actually performing the work defined in the Initiative horizon.


Each Agile framework has certain things in common.

Commonalities of All Agile Frameworks

There is a heavy emphasis on incremental delivery.  In this case, I don’t just mean the final product from the Delivery Horizon, but incremental delivery of whatever outputs are appropriate for each of the horizons.  Whether that is potential initiatives at the Strategy Horizon, Product Plans for the Initiative Horizon, or Working Software at the Delivery Horizon, all of them are delivering something.  And they do this in recurring periods – at a cadence.

All Agile approaches prioritize effort based on value. They may disagree on who and how value is determined, but whatever the value proposition is, that is the basis for prioritized work. For example, a manufacturer might view value as Quality Control. Another might see it as Time to Delivery. A third might view it as Revenue. And there can be a debate on which of those is right. But whatever comes out must be meeting an agreed-upon priority.

All employ an iterative approach. So what is produced in each iteration?  The answer is just a little more than you had the previous iteration.  All flavors of Agile deal with Small Slices of the solution.  And they all have the idea that at the end of each iteration, that work is ready to go.

All agile frameworks promote rapid delivery. In Agile, there’s no more of this waiting until the entire thing is finished and testing it then, finding errors at the end, and having to rebuild large sections. You build a small chunk, check it, and roll it out. And it works when it is built.

It has been tested and approved, which allows rapid feedback.  If it isn’t accepted, you find out almost immediately, before building more on top of something that doesn’t work.

And again, adapting to change.  This goes back to iterative and adaptive planning.  All flavors of Agile have some form of this built into them.

Agile Analysis understands the value of feedback because of its effect on several important aspects of work.

  • Feedback guides the discussion of value. There are many ways that value can be determined. The first thing we need to know as an Agile Analyst is what determines value in the context of your work, company, and customers.
  • Feedback guides Prioritization.  I include this as a separate item because the value equation may change over time. The only way the Analyst will know is from feedback about the change.
  • Feedback informs about Opportunities. But even then, having the information is one thing. Knowing what to do with it is something else.
  • Change is revealed through feedback. It’s important to understand that the change might be because of data. Often when we think of feedback, we are meaning Human Interactions. But often, it’s not people that tell us of the need for change; it is data or other information.
  • Feedback minimizes Uncertainty and Waste.  If we build a means to monitor and tie results to possible responses into all of our business processes, including our development cycles, our time to perform corrections will be lessened.

This page may contain affiliate links. I may receive commissions for purchases made through links on this page.