Author: Angela Wick

Growing up Agile vs. Growing up Waterfall…. Let’s Get Real About What Matters Most!

In my classes I have been increasingly confronted with students who are trying to transition from waterfall to agile,

and more and more students who ask, “What’s waterfall?” Those who have never experienced waterfall think some of the waterfall practices they hear about are completely ridiculous, and I have to agree. Likewise, those who are new to agile and have lived a waterfall life for many years, struggle to see how agile will relieve the pain points of yesterday and today.

The common theme with both groups is that they all need to learn, and in some cases relearn, good analysis, communication, and leadership skills. They need to understand how these skills play together in the BA role to deliver great products and solutions to users and customers, ultimately getting business results.

My biggest concern about most agile transformations today, and especially with the BA role, is that we are unconsciously recreating the same problem we are trying to fix. We have been trying to fix the problem of delivering solutions that users actually want and will solve for their problem for years. We keep fumbling, creating rework, missing expectations, and creating waste in an effort to do it faster over building the right thing. Agile, for many organizations and teams, seems to be just another way to speed up the process. What differentiates agile success from agile pain is if the right agile and analysis practices are in pace to build the right thing, not just build it fast. We are all trying to get great solutions users love, fast and with high quality.

When I hear leaders say, “I want projects done faster,” I don’t think they actually mean that so literally! I have no problem confronting this and asking them about it. When I dig deeper, what leaders really want is outcomes and faster results. The way we measure projects is rarely results based, so faster projects doesn’t get results, and the disappointment ensues.   This begs the question, are we defining and measuring the right outcomes and results? Do they align with what the project is trying to achieve? It is actually agile to do so, and waterfall best practices would agree as well. It is a key part of the BA role to work with leaders and stakeholders to define outcomes and results. Outcomes and results that matter! They don’t want the project done by the end of the month; perhaps they want to start seeing users complete their tasks faster with a new solution by the end of the month. Measure what matters! BAs are the role to define the measurements that matter!

When I hear leaders say, “I want less rework and less missed requirements,” again, I don’t think they mean it as literally as we hear it. What they really want is the right requirements implemented to solve the problem or advance the user and business goals. Getting the right requirements to solve the problem, will result in less rework and less missed requirements. Are you scratching your head yet wondering if you are measuring and focused on the right things?


I also don’t think that leaders want “less defects.” Instead, they want satisfied users, and it’s okay if there are lots of defects with satisfied users. It’s not okay to have users with more problems and lower satisfaction because we have a few really impactful defects.

Not relevant


Speed of project completion

Speed to results and outcomes

Missed requirements & rework

The right requirements implemented

# of Defects

Satisfied users

The issue is that teams and organizations are measuring BAs and teams on the wrong things. And waterfall and agile teams are having the same issues with this. Unless the real outcomes and results from a customer and business perspective are defined, measured, evaluated and tracked regularly, the risk of project waste and failure is high.

It seems obvious, but why is this so hard for organizations to do? The methodology or framework you choose won’t guarantee this happens and won’t guarantee results.

  • No matter if you are working in a Waterfall, Agile, Wagile, Scrumerfall, or whatever you affectionately call it, my real questions are:Are you focused on what matters?
  • Do you know the results that the project intends to deliver from a user point of view?
  • These are not output results like: How much was coded, tested, etc. or if a feature was implemented. I am talking about results that the software creates for a customer or business.

Things like:

  • Decreased the amount of time it takes for a customer to submit a claim from 3 days to 3 min.
  • Increased sales opportunities by 15% by using AI to prospect and predict potential customers.

BAs play a critical role in defining and delivering results, getting the right requirements implemented and having satisfied users. Focusing on defining the results desired, and then managing and tracking them is key!

5 Reasons BAs are Critical to an Agile Team

I am still in disbelief that so many are saying that there is no role for a BA in agile.

Are you still fighting this battle too?

Though it frustrates me every time, I do understand where this idea is coming from, and I want to share some thoughts and perspectives.

Here is my case for both sides of this industry argument.

The “No BA in Agile” Argument:

The Scrum Guide does not say there is a BA role—it says the agile team roles are scrum master, product owner and the development team. Many teams start with Scrum in their agile transformations and get trained on Scrum and certified based on the Scrum Guide. This is taking the Scrum Guide far too literally!

By using this argument, the focus is on titles when that is not what I believe the Scrum Guide authors intended. As a “guide,” it needs to be generic to be readable and understandable to many different types of organizations with many different titles, and also many ways of organizing titles and roles. The agile team needs to be cross-functional and needs to have all of the skills needed to deliver value to the users/customers. Teams that skip analysis, build crappy solutions. Some teams do not use the BA title, but do great analysis and build awesome products, where other roles are doing the analysis. Teams need people with analysis skills for discovery, refinement, prioritization, elaboration, and delivery work. It doesn’t have to be a person with the title of “BA” who does the analysis work.

Historically, BAs in some organizations have been seen as document zombies. BAs in these organizations simply see their role as cranking out endless pages of requirements documentation and to be note takers. If this is the BA role that you know, I agree, this role is not needed in agile. If you, your team, and organization believe that BAs are more than documenters and note takers, and that BAs facilitate decision making, inspire collaboration and conversation, and analyze beyond what others think and say. Then yes, BAs or someone on the team has to play this role. To bring it full circle, I am not advocating for documentation going away. I am advocating that documentation in the form of long detailed spec documents changes to documentation that is useable in agile. Things like visual models as assets that the team uses to inspire deep conversations. Analysis models that help the BA analyze the context of the data, people, rules, and process to invoke the right decisions about impact and priorities.

The “Agile Teams Need BAs” Argument:

In many organizations, BAs have been seen and used as catalysts for problem solving and advocates user-centered solution delivery. These analysts guide the team on the intersection of people, process, data and systems for the big picture and offer a strategic link to the organization’s systems, products and processes. This view of the BA highlights the skill set needed on agile teams.

That being said, many organizations have many talented professionals titled BA, who have a crazy amount of skills to offer an agile team!


Agile analysis is needed for agile teams to be successful. Agile analysis consists of things like:

  • Analyzing the user need and impact desired
  • Defining, measuring and evaluating the solution against impact metrics
  • Leading the team in user centered thinking
  • Creating a product vision, and value centered roadmap and release plan
  • Creating and refining the backlog
  • Elaborating on the backlog just in time with acceptance criteria
  • Keeping the user centered approach in helping the development team understand user scenarios
  • Keeping the user journey front of mind and analyzing for gaps
  • Leveraging feedback loops to update the backlog items as needed
  • Facilitating deep conversations about the user’s goals and needs

So, if an organization uses BAs already and believes this is what BAs do, it seems counter intuitive to not have BAs do this work on an agile team.
If organizations have never used BAs previously, they may need to consider it to make their agile teams more successful.

5 reasons why Agile BAs are critical to an Agile Team

1. Many large organizations are struggling with the product owner role. They need BAs to partner with POs to bring customer focus as the team refines the backlog and delivers the work. BAs help manage value delivery!
2. BAs have a holistic and detailed view of the customer, user, data, processes and systems. Without this view, teams will struggle to deliver solutions that hit the speed, relevance, and quality metrics leaders are looking for agile teams to hit.
3. BAs truly care and have compassion and empathy for users. It’s in their DNA! When empowered to make users and customers awesome, BAs will rise to the occasion and represent the user needs on the team.
4. Great BAs speed up the team by having backlog items ready for the team. BAs can facilitate high-quality and fast feedback loops with users/customers which are critical to agile, speed and innovation success!
5. BAs are T-Shaped skilled team players. Great BAs have a wide skill set that comprises of technical, leadership, business, analytical, facilitation and communication skills needed to help agile teams thrive! T-Shaped team member are those s that have deep expertise and have the ability to collaborate cross functionally and apply their deep knowledge and skills in other areas to benefit the team.

Is agile analysis leading to success on your agile team? Are BAs empowered to truly play a BA role to help their agile teams deliver real value?

If your team or organization is taking the Scrum Guide too literally and missing out on analysis, you might be missing the key agile success—using an Agile BA!

Top 7 Things BAs should be Doing on an Agile Team

If you are like most BAs today, you are either on an agile team or know that it is coming soon!

Here are the top 7 things that BAs should be doing on agile teams. 

  1. Practicing the product vision in the mirror every day.

That’s right! Know your product vision and know how to communicate it to different audiences, different ways with a consistent message about why the solution is needed, who it serves, and how success will be measured. This typically is some sort of vision statement and high-impact metrics. Together these focus on the result that is expected from the solution.

 For example: The new CRM solution is a solution for our sales executives and account managers to better understand their prospects and customers. Unlike today’s solution it will provide a faster way to find prospects, qualify them, prioritize them and sell to them.

 Even if you are working on defects and enhancements, your product/solution needs a vision!

 As BAs we need to constantly remind the team and stakeholders what the vision is! It helps us help them make decisions, weigh trade-offs and set priorities. It helps everyone stay focused on the user and understand what direction we are headed.

  1. Defining the measurable impact the product is expected to have on the end users and/or customers.

Along with the vision are the high-impact metrics that define the results we are looking to achieve in more detail. These are the BA’s keys to managing stakeholders, priorities and proving BA value.

These metrics should be customer and value focused as well as measurable.

For the CRM example, a metric might be conversion rates and time lines of new prospects. With this we need to know the current numbers and a goal we are looking for this solution to achieve. For example: Today we convert 10% of prospects with an average of 6 months from first contact to first sale. Our goal with the new CRM is to convert 30% in 3 months.

Even projects and features that seem to not impact the end user or customer need to be looked at again.  They typically DO impact the customer in some way, and most organizations can’t afford to impact them negatively.  In these cases you will need impact metrics for both the business and the user/customer.

We track these metrics as we deliver small increments and see how each increment is making a difference in the metrics.

  1. Measuring the impact metrics every 2 weeks or more to see how the team is progressing toward the needed results.

 Yes, a BA can show value by not just defining the metrics but showing the team’s delivery work is moving the metrics in the right direction!


  1. Facilitating feedback loops and working to shorten the feedback loop by defining small slices that the team can get real user/customer feedback on.

 In order to get the metric truly performing we need feedback from the users to see how they feel it is helping them achieve their goals. So, BAs work with the team and stakeholder groups to facilitate frequent feedback loops. Increasing the frequency of feedback loops, requires small increments to be defined in the backlog that the team can get feedback on! BAs, you are on it!

  1. Prioritizing backlog items with the PO that move the high-impact metrics.

 To move these metrics, BAs need to help the PO prioritize what features, enhancements, defects and details will matter most to the metrics. Analysis is key here and BAs are at the center of it!

  1. Refining backlog items to only get the minimum built to move the high-impact metrics in the right direction.

To really make an impact, the analysis BAs do must work to minimize the delivery effort needed to meet the metric. This often means limiting our tendency to work in “feature bloat” mode and only focus on what matters to move the metric. I hear many teams are focused on MVP, and that is really tough if we don’t know what metric we are trying to move with an MVP. Again, BAs are at the center of this critical analysis work to deliver value fast.

  1. Inspire analysis and innovation in others on the team with use of visuals, models and charts that help ignite creativity and problem solving.

BAs who use conceptual visuals that are user focused can be a catalyst to a team’s innovation and problem-solving engine! Lightweight models and visuals make a huge difference! Are you ready to make it happen?

Agile BAs are a critical part of agile teams and can bring tremendous success to the team’s overall performance. Are you stepping up and being the best agile BA you can be?

What BAs Do to Remove Bias in Machine Learning

Do machines make better decisions than people? This is a question every BA should be pondering and debating.

Machine learning and other artificial intelligence capabilities are expanding to every industry. Machines are analyzing data to write news articles, predict when car parts will fail, identify customer emotions, detect credit card fraud, drive cars, diagnose cancer and identify criminal behavior.

What are the consequences of bad decision making in these areas? Biased data could prompt machines to make decisions with consequences ranging from fake news and irrelevant advertisements to false arrests and even death.

Many companies are wasting millions of dollars developing innovative products that fail to meet expectations. A few companies are getting it right and thriving. What’s the difference? Well defined outcomes and good analysis!

But it’s not traditional analysis. With machine learning, the machine learns the decision logic on its own through patterns and does not have to be explicitly programmed with a logical specification of requirements. The machine, not the BA, uses data to identify business rules and many requirements. Does this mean BAs are obsolete? Absolutely not! BA skills are even more important when we are relying on machines to make decisions. Why?

Because machines still don’t make good decisions without people

People play a different role in machine learning! BAs working on machine learning projects shift their efforts from traditional requirements elicitation and analysis to have more focus on experiments and solution evaluation.

Solution evaluation is about looking at a constructed solution, machine learning algorithm perhaps, and how it is serving user and business needs. The solution doesn’t have to be fully built to be evaluated—a prototype or minimum viable product is great starting point.

Here’s what the solution evaluation cycle looks like:

wick 07302018a

Define Desired Outcomes

Many machine learning solutions fail because teams focus solely on technology and ignore the context, purpose and desired outcomes. At the beginning of any new project ,this is a key step for BAs. In the case of machine learning BAs will define (and continuously refine) desired outcomes based on understanding four factors:

  • The users/humans who are the source the data the machine is using
  • The empathy state of the user and their processes and workflows
  • The potential biases of user group and the source data
  • How to analyze the machine’s output and clean up the data to remove bias that creates practical and ethical issues


Understand Data

We’ve all heard of GIGO, right? Garbage in, garbage out. That’s especially true for the data used by systems that make automated decisions. If one data point is wrong, missing or misinterpreted, the organization and the user will suffer consequences.

It’s the BAs role to understand the data and continuously evaluate the data set. BAs help the team gain confidence that the machine has the right data to solve the problem and move the outcome in the right direction. BAs need to know:

  • Where the data is coming from
  • How the data is influencing the decisions made by the machine
  • Which pieces of data are meaningful to achieve the desired outcomes

Let the Machine Learn

One pitfall for teams is spending most of their time and energy defining, building and analyzing this part of the process. They get so focused on the actual machine learning technology that they miss out on the importance of learning iteratively through experimentation and analysis.

This leads teams down a path of self-destruction as teams fails to make connections between the technology, the data, the customers and the desired outcomes.

Experiment and Analyze

Successful machine learning solutions require multiple cycles of experiments and analysis. This effort gives us insights into what needs to be fixed. These insights are much more meaningful than reacting to a list of user requests. BAs use these insights to change the data, refine the questions and the modify the variables to discover the impact on how the machine learns.

But BAs do not do this by themselves in their cube! Instead, it’s a collaborative effort that includes the customer or at least a customer-centered approach. To help the machine make good decisions, BAs use experimentation and analysis to:

  • Observe what is and isn’t working for the users/customers
  • Analyze the business and user metrics that matter to outcomes
  • Analyze the user experience, customer experience, data flows and processes to determine how the overall process and solution is performing
  • Analyze real-time data to see how users are interacting with the solution
  • Identify any data that is introducing bias into the machine’s decisions

Remove Bias

After teams experiment and analyze, it’s time to refine the desired outcomes and update the data as needed to achieve the outcomes. A big part of that process calls BAs to remove biases identified in the machine learning results.

The team manages biased data in several ways. They can:

  • Remove biased data
  • Retrain the machine to handle bias data differently
  • Adjust the input process of users to remove/address the bias data

Teams that skip or minimize experimentation and analysis waste millions of dollars on projects that fail. Help your machines make better decisions by advocating for the importance of customer interaction, context, data quality, outcomes and refining the data based on experiments.

Machine decisions should make sense for our customers and our organization. And that requires a human (BA) touch!

User Stories: Your First Step Should Always Be Back

Have you ever played an outfield position in baseball or softball? As an outfielder, your primary responsibility is catching pop flies.

When you hear the crack of the bat, there’s a moment of panic as you try to figure out where the ball is headed. For young players, their first instinct is always to run forward, which usually leads to the ball flying over their head and the batter advancing several bases.
When I played softball, my coach had a mantra for outfielders, “Your first step should always be back!” The coach asked the outfielders to take a quick step back, gauge the ball’s trajectory and then choose their approach.

Our backlogs are filled with hundreds of pop flies. And to build better user stories, our first step should always be back. We need to step back, check our sources and analyze the big picture before we decide how to proceed.

Where Do All These Pop Flies Come From?

When the backlog items come flying at you, it’s important to take a step back and figure out where they are coming from. Are your stakeholders like methodical ace pitchers or are they wild and erratic? Does the product owner swing at anything or do they evaluate each pitch to see if it’s worth a swing?

Most backlogs are filled with a random mix of enhancement requests, defects, and ideas submitted by a random mix of stakeholders. If BAs work the backlog as is, without discovery and analysis, the team will struggle. Delivery will be slow, teams will build the wrong things and customers will be frustrated. BAs will be bogged down by a never-ending backlog of more requests and missed requirements.

Existing backlogs need to be aligned to strategic priorities. BAs need to step back and look at how backlog items connect and how they align with organization goals. Ideally, BAs analyze and transform these submitted backlog ideas into better user stories that give stakeholders and end users what they really need versus what they think they need.

Work with Your Pitcher and Batter

After you step back and really examine the backlog of pop flies, it’s time to tame your wild pitchers and help your batter develop a more selective swing. The discovery process engages project leaders and stakeholders to develop a shared understanding of needs and priorities. It’s all about getting the team thinking and talking.

Ideally, and good practices is for BAs to use multiple techniques to help teams discover what’s possible and solve problems. The most effective discovery sessions help teams generate ideas, evolve and innovate. They include collaborative elicitation experiences that inspire meaningful dialog between stakeholders.

Just sitting around a table and talking isn’t enough—build engaging activities, prepare thought-provoking questions, get people moving by building visual models with sticky notes or drawing on white boards, try gamestorming, etc.


Go Moneyball

As the team moves through the discovery process, it’s important for BAs to make time for moneyball.

Do you remember Moneyball? Adapted from a book of the same name, the popular 2011 movie tells the story of famous baseball guru who stepped back, analyzed the game and changed the way organizations build winning baseball teams.

This is the job of every BA. “Go moneyball” on the backlog and user stories! Analyze the results of the discovery sessions to reveal gaps, make connections and define the real problems.

BAs can’t skip analysis. This BA thinking time, outside of the discovery sessions, is where BAs really boost the value they provide. When BAs analyze processes, data, and people, they find impacts and gaps in known requirements and ultimately deliver better solutions. This is the time to pull out your analysis models and techniques to help you think and analyze.

Getting the WIN!

When BAs take a step back, create engaging discovery activities and make time for analysis, teams are much more likely to get the win. But remember you don’t just move through these steps once. You don’t just look at the backlog, do one discovery session, then analyze and go— it’s an iterative process.

BAs repeat the elicitation cycle over and over as they dig deeper into details. You’re really playing ball when you find ways to experiment with and test what you’ve learned from discovery and analysis.

Good user stories and good requirements in general, always come back to the basics of business analysis and making sure we advocate for the elicitation and analysis pieces of our BA approach. Don’t just chase after every pop fly that comes your way. Make sure your first step is back so you can get the perspective you need to help your organization win.