Category: BA Basics Series

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.

The Basics of Agile part 2 – The Waterfall Watering Pool vs The Agile Aquifer

The Basics of Agile part 2 – The Waterfall Watering Pool vs The Agile Aquifer

Welcome back to Part 2 of the Basics of Agile series.

Going back to Part 1, we talked about the motivations for Agile, and how change is an important part of those motivations. The standard for Waterfall required planning the end-to-end solution well in advance of the beginning of development, and any changes to that plan were difficult to apply once development started. Over time, this created an environment where the gap between the need vs. the met needs never narrowed. In other words, because of the rigidity of adherence to the plan, the results left the customer further behind.

Then Agile comes along and does away with planning. Problem solved, right?

Wrong. That is not what happened. However, it is a false perception.

Planning in Agile is more of a fluid process.

Water Pools for the Waterfall

I will illustrate the need for fluidity with this little story I call “The Waterfall Watering Hole.”

Imagine that a village Chief has contacted a designer to come up with a way to provide water for the village. After meeting with the Chief and other village leaders, the Designer begins his work coming up with a plan. After years of research, the Designer comes out of his hut and contacts the Chief. “I have a great design for the village water needs. It is timeless and has worked in villages for millennia.”

The design called for a large water storage pool. All the water would be stored there. According to Waterfall Designs Inc., an internationally recognized water supply thought leadership group, a single large pool is the proven method for holding water. The village water supply designer adds, “No one ever died of thirst when living near a large pool.” The design was presented to the village Chief and other leaders.

The Chief is impressed but notices the cost. Still, trusting the Designer and seeing how he had not emerged from his hut for so long, the Chief believes the Designer and approves the work. Besides, he learned a new word, “reservoir.” Without knowing what it meant, the Chief thought it had to be very impressive.

Because of the costs, he also stops eating meat to save money for the project, and to lose weight. But mainly it’s the money. The butcher is not pleased with losing his job.

The work commenced. For project integrity, access to the project was denied until the water pool was finished. No alternative sources of water and no changes to size or design would be allowed because the Chief is already on a diet.

Construction took a very long time. As the saying goes, “the natives were restless” with anticipation of finally seeing the results.

When construction ended, everyone was excited to see the water pool.

Yet over time, the water began to taste strange. Someone said, “This water is stagnant. Algae is forming on the surface.” But having the water pool was so much better, no one said anything until more problems arose.

Then the water began attracting wild animals, and what everyone expected to meet the village’s needs now was being drained. At current rates, the water would only last through half of the dry season. A concerned citizen group formed for Water Pool Reforms and asked me to be a spokesman. I ask the Designer if the pool could be bigger since the animals are drinking it all. The Designer says, “The storage pools were designed to the specifications given when this project began. These concerns should have been raised back in the design phase.”

Because these are thirsty wild animals, getting water has now become dangerous. The Water Pool Reforms group sees the need to get further away where it is safer. However, no one can carry the water from the pool around, since there are no containers. So everyone has to stay within range of the pool, and the wild and dangerous animals. You begin thinking, how can we make this portable. I ask the Designer, “Can I have some kind of container so I don’t have to stay where these dangerous animals can eat me or my family?”

“No, storage pools is the approved design,” the Designer says. “The village Chief has approved it. I do not want to have to face him again. He is always in a bad mood on his diet and does not have time to address all the needs. You are lucky to have gotten this much.”

Then there came the mosquito problem since there is a large body of standing water. Eventually, villagers begin to catch malaria. My whole family has gotten sick with the virus. I ask the Designer, “Can I have mosquito nets added to my home?”

The Designer said, “No. That would be outside of the scope of the original project, and the added expense will not be approved. Besides, we have just entered the maintenance support phase, so no changes can take place on this project. If it is broken, then you can create a trouble ticket. But it is working as designed, so we will not do anything about it. I’ve been contracted for the next village water project.”

As the Designer walks off toward the next village, he turns and says, “You complain a lot. Good luck getting any changes with that attitude.”

Fed up and trying to hide a snarky tone, I respond, “Thank you for your time.” But as the sting of the Designer’s rebuke wears off, I cannot help but think, “Was there ever a time when changes could have been made?”

That is an excellent question.

The storage pool ends up causing several problems while inadequately addressing one.

How would Agile approach this problem?

The Agile Aquifer

If Waterfall provided the Watering Hole, then the Agile response would be the Aquafer. That story goes something like this.

The village leaders ask a designer to help them have a source of water. The Designer spends a little time researching what thought-leaders propose, just to get some ideas. “Water Pools are a great answer,” she thinks. But she also had read about other methods that are far less glamorous, and wonders if that would be a better option. So, having that as a base of information, the Designer compares the various hypotheses by talking to the villagers. She begins to understand their needs and how to determine the best answer.

To her surprise, the global thought-leader’s ideas were soundly rejected by everyone in the village. People from other villages mentioned that storage pools are expensive, take a long time to build, turn green with algae, tie you down to gathering food close to the water pool, attract mosquitoes, brings in malaria and attract dangerous animals.

“Wow, the eggheads missed that one,” she thinks.

The Designer asked if the people wanted running water into their homes. She got an estimate of the cost of that proposal. Although everyone liked the idea, the Chief decided to leave that for future generations because of the cost. As he sits down for dinner (on a stool that barely supports his weight), the Chief says “Ms. Designer, please find a way that does not cost so much, but is still safer than the water pools. Perhaps when the village grows, we can address that option. We just do not have the tax base for it.”

The Designer took all of this information into consideration and came up with a less expensive and safer proposal – a water spicket located in the center of the village.

She showed her proposal. It was not very flashy. No big construction would need to be involved because the minimum viable product simply required to provide safe water. It did not need to store water, just provide it. The key was, the water was already there, only underground. The Designer began her presentation, “I have a proposal that has worked for millennia, and I’m sure it will meet your needs.”

The Chief was surprised that he had such a great water resource available and claimed great personal wisdom to access it. Plus, he had looked up the word millennia, having heard it used on neighboring water projects. Additionally, he had heard about neighboring Chiefs losing weight after expensive water projects. So if it provided for his people, maintained his lifestyle, and plausibly made him look good politically without going on a diet, then he was agreeable. “But I want to see how this project progresses,” he said. “We need to verify this will meet the people’s needs.”

A drill began digging the route through the surface for the pipe to go down into the aquifer. Everyone came to see as a water pipe was installed. The villagers review safety standards and approve each segment of the pipeline.

However, while the spicket is being built, the villagers ask the Designer if they could carry water with them as they gather food. A change request is made and sent to the Chief for approval. With the cost of the original estimate for the water spicket being so much less, the Chief was able to fit this into the village budget (along with an increase to his hefty meal plan). He was in a very generous mood these days since he was getting such a favorable result in local polling. So the additional work is authorized to supply bottles and other containers of various sizes. A family can store water in containers or bottles, with just enough to meet each family’s needs. Because the water bottles are lightweight, families could bring water with them and gather food much further away.

The village became a trendy destination for immigration in the region, which added to the Chief’s voting base. With the economic growth, a study is being done for the Shake Shack and other businesses to have running water installed. The Designer of the spicket project has been retained to assist in that effort.

So summarizing the results, with the spicket design there are no standing pools. That had benefits missed by the Watering Hole, such as no stagnation, no algae, no wild animals, no mosquitos, and no malaria. If you need more water for a period, you could always fill up more bottles. If you need to go extra far to gather food, you can carry them with you on a journey.


I know these little stories are a bit ridiculous. But they do illustrate several aspects of Agile, as well as it’s advantages over Waterfall. The second story illustrates the Seven Principles of Agile Business Analysis, as taken from IIBA’s The Agile Extension to the BABOK Guide v. 2. These principles are:

• See the Whole – Get a big-picture view of things. Researching options.

• Think as a Customer – Capturing various opinions and values of everyone involved. Talking with the villagers.

• Analyze to Determine What is Valuable – Determining tradeoffs between opposing options. Determining health and safety is a concern.

• Get Real Using Examples – showing various alternatives. Asking about Water Pool models.

• Understand What is Doable – adhering to budget constraints. Rejection of the running water to everyone’s homes.

• Stimulate Collaboration and Continuous Improvement – Adapting to new improvements as more information surfaces. The villagers were coming up with additional ideas.

• Avoid Waste – The least-cost option that provides the desired result. Choosing the spicket model instead of the Water Pools or Running Water systems.

I will talk more about the Principles of Agile Business Analysis in my next post.

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.