Category: BA Essentials

Announcing – AAC Certification Course on Udemy

Announcing – AAC Certification Course on Udemy

Hello everyone,
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.


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.

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.

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.

Basics of Agile part 3 – The Principles of Agile Business Analysis

Basics of Agile part 3 – The Principles of Agile Business Analysis

Welcome back to part 3 of the Basics of Agile series, where I focus on Agile from a Business Analysis perspective. This article introduces the Principles of Agile Business Analysis.

These principles are detailed in the Agile Extension to the BABOK® Guide (Agile Extension) from IIBA. This book, as the title suggests, is an addition to the BABOK®, also known as the Business Analysis Body of Knowledge®. Recognizing that there are special considerations for projects utilizing Agile methodologies beyond those presented in BABOK®, IIBA teamed up with The Agile Alliance to produce the Agile Extension.

The Principles of Agile Business Analysis are:

Agile Extension to the BABOK®  Guide – section 2.6

In the first article of this series, I talked about basic things being profound. Each of these principles may seem very simple on the surface. Yet, when they are understood thoroughly and combined, they are potent declarations that guide our work as Agile Business Analysts.

Here is why.

See the Whole

There are multiple ways this phrase can be applied, depending on the context. For example, on a Strategy Horizon level, it could imply seeing all of the capabilities of an organization, and how those capabilities fit together. On an Initiative Horizon, See the Whole could mean looking at all of the processes involved for a feature. And on a Delivery Horizon, it could mean having complete requirements with an understanding of how that requirement meets the broader goal.

Or, you could take another view. See the Whole could imply completeness of involvement from all stakeholders, ensuring no one has been left out. Or, have all environmental factors have been explored.

No matter how you look at it, the concept of See the Whole boils down to two things – Scope and Completeness. Do we cover the entire range of impact for the initiative or piece of work? Does it represent that range fully?

Think as a Customer

Aside from the concept of iteration, there probably has not been a concept more talked about in Agile than “Think as a Customer.” As Agile Business Analysts, doing that requires much interaction. Your guesses about what is wanted must become hypotheses to be questioned, and eventually confirmed or adjusted through your communications.

It is OK to make an initial guess and allow yourself to be wrong because the goal is to eliminate what is wrong. Eventually, this will enable you to understand what is needed and, more importantly, why it is so important.

Then, when relaying the information gathered, your voice through verbal, models, text, or any other communication, having developed that knowledge from the customer of their needs, becomes the Voice of the Customer.

Analyze to Determine What is Valuable

Value is the primary tool for prioritization. However, “value” can mean many different things depending on context and who perceives it, i.e., “Beauty is in the eye of the beholder.”

It can also depend on timing. In markets during a boom period, value can be seen everywhere. If a market busts, however, value can be challenging to find.

Value can be fleeting. That is why we analyze and why the analysis repeats over time. Especially at the Strategy and Initiative Horizons, the analysis will be repeated to confirm the necessity and priority of initiatives. Similarly, the value analysis occurs at the Delivery Horizon for the priority of work to be done for an initiative.

Get Real Using Examples

In Real Estate, often listing agents will insist that the seller stage the house so potential buyers can better visualize how the home functions. In essence, that is an example of Getting Real Using Examples.

Examples do several things. Primarily, they confirm understanding with the customer. If the example is not correct, the customer helps inform the analyst to change it. More than that, examples can be viewed in an A vs. B comparison, allowing a decision on alternatives. The examples can be of a design, process flow, calculations, or function. The beauty of examples is that once they are accepted, the example can easily be communicated to the development and testing teams as part of the requirements. In that way, examples are an essential element of a shared understanding.

Understand What Is Doable

To start, the word Doable is a relative term. Many factors can determine the feasibility of work.

That said, one of the critical elements of Agile initiatives is visibility. With visibility, all involved can see how the initiative is coming along and what is coming next. Yet if something is difficult, perhaps no one wants to admit something is too difficult for the value gained. Developers often think they can solve any problem. That is human nature for problem solvers.

Agile has a way to handle the problem. The short version is – knowing about added time or costs before performing work allows the customer to decide whether a feature is developed, altered, delayed, or removed.

A typical scenario for how that works follows this path.

At some point during what some methodologies call “grooming,” the Agile Business Analyst or Product Owner has given estimates on the work items. Those values are communicated to the customer. Then the development team has the opportunity to place their revised estimates on the work. If the estimates are significantly higher than expected, the customer would receive feedback about that feature and make a decision. This creates an opportunity to perform a cost-benefit analysis. If that assessment shows the function costs more than the customer values, then it either receives a lower priority, a revision, or it is canceled.

Alternatively, doable can be a firm constraint. The Agile Business Analyst must understand the capabilities available to the team. Perhaps a technology is not as stable as thought. Maybe we do not have a critical resource. In those cases, no matter what the value is, that feature is not doable until the constraint is removed, if removal is possible.

Whether “doable” means additional time or resources, or technical limitations, in either case, these items may generate a change request to account for the extra time or resource requirements.

Stimulate Collaboration and Continuous Improvement

I think this is two different items, but there are more areas where they overlap than where they do not. There are some areas, such as manufacturing, where improvement can come from process observation and adaptation based on empirical data. The counter-argument is you could acknowledge that the Agile Business Analyst would not know about those empirical computations unless told in some way.

Given that these are not synonymous (but mostly overlap), the point of collaboration is to bring about improvement. Every interaction with a customer, subject matter expert, or development team has the potential to make the result better. All collaboration, therefore, contributes to Continuous Improvement. This principle is a reminder to take advantage of that opportunity.

The Agile Analyst does need to stimulate collaboration. Customers are busy, and it will take an effort to convince them of the need to engage. Yet with Agile, gone are the days when the responsibility for the result is wholly handed off to design and development. Now, to some extent, everyone is responsible for outcomes. Often a reminder that unclear or incomplete requirements are an unacceptable risk can help a customer understand just how important collaboration is to the effort.

Avoid Waste

When I said everyone is responsible for outcomes, that holds for successes and failures. Avoiding Waste means avoiding failures such as rework, missed requirements, or features not directly traceable to Customer priorities. Waste could be not seizing the opportunity to change – an opportunity cost. It could be that the team did not work efficiently. Or the work did not function properly. All of these require revisiting what has been done and creates churn.

The point of the previous six principles culminates in avoiding waste. That means no waste in the final deliverable. It also means no waste in any step along the way. Waste can also be seen in cycling through discussions about the same feature due to indecision during the requirements gathering sessions. Waste can be seen where communication is either not clear, or not received clearly, requiring repeated attempts to clarify. In those cases, again, it comes back to feedback and experimentation, so that the need is observed, an improvement attempted and results confirmed.

So waste can take many different forms. But does that mean any repeated effort is waste?


Perhaps at this point, it would do well to define waste, or at least describe it as associated with different roles or initiative phases.

What is Waste?

I’m not opposed to asking what seem like obvious questions. In practice, if the problem of waste were simple, then we would have a lot less of it.

Keep in mind that Agile is iterative, so there are some elements of repetition. Repetitive tasks may or may not be wasteful. It depends on the purpose of those tasks.

Next, remember that decisions may differ once a hypothesis is confirmed or refuted, and often the experiment is repeated to show results over time. This is especially true in the Strategy or Initiative Horizon. So the work of analysis is often repeated. Yet, the goal is not to have wasted effort. The effort of analysis must have a purpose toward helping make the best decisions.

Alternatively, there is waste associated with the deliverable. There are a few sources for these kinds of waste. First, if the requirements are not complete and correct, then the deliverable will be wrong. If you use the wrong map, you will not get anywhere. Likewise, incomplete and incorrect requirements will leave the team going in circles instead of making progress.

If the team does work that is off the script, that is another form of waste. On my first Agile assignment, a developer reported that he was being pulled away by other responsibilities. That was an issue that affected the capacity of the entire team. After recognizing the problem, we had the developer refer any outside request for his time to me. Technically, in that organization, the Scrum Master should have handled that, but that role had gone through some change in personnel (3 in 6 months).

If the team does something that should have been at a lower priority, again, that is a form of waste. Work should be done with the most valuable item first, so long as those requirements are complete and correct. Agile addresses this through collaboratively reviewing the requirements, features, and functions with the customer to determine what is most valuable.

Finally, there is waste due to error. If everything were perfect as envisioned during design, there would be no reason to test. However, we need to realize that testing is the last line of defense against a problem going into production. This is why there are multiple layers of testing, by members of the development team, by specialized test engineers and as part of User Acceptance Testing.

I have spent much time on Avoid Waste. Yet, as you can see, the prior six principles all play a part in Avoid Waste.

When you think of it that way, perhaps this entire article can be re-purposed as a primer on how Agile attempts to avoid waste.

Basics of Agile part 1, What is Agile?

Basics of Agile part 1, What is Agile?

“Gentlemen, this is a football.”

Vince Lombardi

Welcome to the first of the Basics of Agile series.

Basics are profound things. The more elemental, the greater the impact.

Admittedly, if you are well experienced in Agile and see this article series, you might feel a bit like the Green Bay Packers when Coach Lombardi uttered the famous quote. “Gentlemen, this is a football.”

“Yeah, Captain Obvious.”

But knowing what it must be like in most locker rooms when a great team is underperforming, perhaps the team was instead thinking, “where can I hide?”

Many coaches are known to “peel the paint” at halftime. Instead, the Packers hear this most elemental instruction. They relax a bit and start to remember their training, what they have worked on all season. I can hear the team now, or at least their thoughts – “Yeah, Coach, we know what a football is.” In the second half, they acted like it and came back to win the game.

Sometimes even for those that are experienced, like the legendary Packers, the only way forward is backward. At least, it feels backward.

There are times when we catch ourselves going through the motions. We all need reminders.

When a college basketball player that could shoot the lights out in high school cannot get the shot off in college, what can he do to fix the problem? The answer is often fundamental mechanical changes – how the player shoots. The only way forward is often going over the basics again. The results can be, in a word, profound.

On the other hand, maybe you are new to Agile and need a primer. All of this is new to you, and you need Cliff’s Notes version to help you wrap your head around it all. Trust me, I have been there.

Why is this such a big deal?

It still boggles the mind that a statement that can fit on a napkin, The Agile Manifesto, has been expanded into endless 3 inches thick volumes by multiple authors. So, what is my answer to that? Well, I guess writing about it too, adding to the digital pages on the subject. However, I promise to get to the point in this series rather quickly. At least before page 500.


Instead of going into the history of Agile, I will talk about the motivations that brought it. Motives usually have more to do with origination anyway. Or putting it more familiarly, “Necessity is the mother of invention.” Perhaps that is why Simon Sinek’s message on “Find your why” resonates so well. So, why did Agile come to be?

In previous decades, the de facto standard for software development, Waterfall, was based on a project model primarily used for engineering projects. However, that model did not perform well for software development. The problem?


Unlike buildings or cars, external and internal environmental factors caused the requirements for software to change faster than the software requirements could go through the processes of planning to development. Waterfall proponents thought that planning heavily before a project began would lower the number of problems. There is a logic to that, but the logic did not match the anticipated results. Planning too far in advance, without the flexibility to adapt, caused more problems than it solved because the environment changed before the product delivery. The gap between need and met need never closed. Actually, it widened.

A new methodology was needed in which change is embraced as part of the process, and that allowed changes to requirements to be performed as late as possible before it was developed. Several methodologies arose to fill that gap, including Scrum, XP, Rational, and others.

The thought-leaders of those methodologies came together a couple of times to discuss how best to proceed. Eventually, they agreed on a simple statement that highlighted what was in common. That statement is called The Agile Manifesto.

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.

There have been several different attempts to expand this manifesto into principles by organizations such as The Agile Alliance, PMI, IIBA, and others. Eventually, I will go into those proposed by the International Institute for Business Analysis (IIBA), since I am a Business Analyst. For now, I will offer my own take. This will be more exposition than a list of principles since I like to take things apart when writing about them.

First, the opening phrase hints at experimentation and empirical analysis. “We are uncovering better ways…” Agile is not a prescription, but a series of hypotheses. The intention is to find what works and do that. Whether you communicate this way or that, deploy in 2 weeks or 6 months, document through napkins or repositories – the Agile approach is to do what works for this endeavor. Those decisions might bomb on another project – even one involving the same people. However, Agile would observe and refine until it works.

“…by doing it and helping others do it.” Perform the experiment, observe the results, and share the findings with others. Feedback is built into any Agile environment from Strategy to Initiative to Delivery. Additionally, feedback is built into collaborative structures, research activities, and decision processes.

Then there are four value statements. These do not mean to focus on one to the exclusion of the other. Instead, the balance simply leans toward the left side instead of the right. The idea is to keep the focus on what is more important without neglecting those items that support the goal.

Individuals and interactions over processes and tools

The first value statement shows that it is more important to have the right people working collaboratively than have the right tools and processes. Give a team the authority to self-govern, and they will figure out what works. Expensive tools may not be necessary and can even distract.

The most efficient project I have worked on used the simplest of tools to manage the project. It was a travel and expense reporting project for an international consulting company built on a SAP HANA database to provide high performance. Team members were located in Florida, California, Kentucky, and Ukraine. This project managed quite well with the requirements captured in a spreadsheet. Each row was the equivalent of a User Story, with additional requirements that were recorded in a parallel spreadsheet for each story. There was no project management or requirements management tool. Nor was there a Kanban board to track story progress. All statuses were maintained on the appropriate row in that shared spreadsheet. Daily stand-ups were guided by a filtered list of active status rows. They splurged on getting the best development and database environment instead of high-cost project management tools that impose time and cost overhead.

As efficient as that was, it helped that the entire development team were very experienced developers, each having a master’s degree in computer science. Other teams might not have pulled it off.

Working software over comprehensive documentation

Next, the main thing is to have software that works. If it does not work, then the documentation does not matter. Keep focused on the desired result. One of the misconceptions is that Agile de-emphasizes documentation. Instead, it values timeliness of documentation that is verified by the customer just ahead of development. That means the product is based on the latest information possible. Even then, the point is not to have the newest documentation, but to have working software. Each iteration is a commitment to producing something that works. 

Customer collaboration over contract negotiation

Customer collaboration is more important than contract negotiation because customer satisfaction is not measured by a contract or statement of work. Agile understands the protective importance of a contract. They are defensive documents to describe the minimal working expectations. However, contracts are not intended as guides to product delivery. To know what is expected, you have to talk with the customer, not the lawyer. If you want repeat business, begin on friendly terms by collaborating, referring to the contract as an arbiter if the relationship is dysfunctional. Focus on building functional relationships, and you will not have to worry about dysfunction.

Responding to change over following a plan

Responding to change versus following a plan because the plan is not flexible enough to adjust to the current organizational needs.

Originally, Waterfall methods were intended to be iterative and allow change. In practice, gaining approval for change requests was difficult, and changes were viewed with much disfavor. Changes to the original plan were strongly discouraged. This effectively killed the change request processes. Opportunities to utilize the latest and best information were ignored so that the original plan would remain intact. There was a need for something different, both in the methodology and in the project output. Waterfall prevented both.

Change is built into any Agile environment. That does not mean there is no change request. After all, you do need to control cost, and CRs are how those costs are approved. In Agile, change requests may alter timelines and priorities, but they are included without sinking the project. The reason Agile approaches were envisioned was to handle change better.

The Agile Mindset

Looking at the implications of The Agile Manifesto, the importance of those four value statements is as profound as Lombardi’s football. They are a call to keep the focus on the basics of customer value, collaboration, feedback, and delivery of working results based on the most current information available. The Agile Manifesto codified a different way of thinking about initiatives and the relationships required to do the work.

Next, I will begin discussing Seven Principles of Agile Business Analysis, based on IIBA’s Agile Extension to the BABOK® Guide, which bring even more guidance to how Business Analysis works in an Agile framework.