Skip to main content

Author: Angela Wick

BATimes_Apr27_2023

Best of BATimes: Six Effective Elicitation Questions to Ask Your Stakeholders

Written by Angela Wick on . Posted in Articles.

Asking questions during interviews or as part of a structured requirements workshop is commonplace. However, the most important question is one you should be asking yourself:

Am I asking the RIGHT questions?

Here are a few of my favorite elicitation questions and what they might reveal about your project.

 

1. What are the biggest challenges in your role?

A key part of any BAs role is to understand the context of the project: where does this project “sit” within the larger organization.
Having stakeholders describe the challenges in their role prompts both leaders and doers to share information that moves “outside the box” of the project.

Especially in an interview setting, this question allows the collection of “stories” that will elaborate and cement the value of the project and its required capabilities. These “stories” are concrete examples of the business need that will communicate the value of the project to sponsors, vendors, testers, developers, etc. throughout the project lifecycle.

Though you want to be cautious to avoid scope creep, briefly stepping outside the confines of the project can also help you identify:

  • Organizational risks
  • Missing stakeholders
  • Requirement gaps

 

2. What does success look like?

As I noted in my May article, “The Top 5 Mistakes in Requirements Practices and Documentation”, many project teams spend too much time focusing on the as-is current state.

Asking stakeholders to define success is a perfect way to move workshop or brainstorming discussions from the current state into the future state.

In the initial stages of elicitation, this question will help gather a clear overview of what capabilities are required for the project. The output of this question to can be used to create high-level conceptual models of the future state.

This question can also be used in beginning to elicit requirements for very specific features and capabilities. The challenge will be keeping stakeholders focused on the “what”: users, processes, rules, events and data. The discussion migrating to technology, systems and solution may risk that the true needs go undiscovered.

Perhaps most importantly, focusing on success frames the discussion in a positive light, emphasizes benefits, and gets stakeholders excited about the value the project will provide to their organization.

 

3. Who do you think is impacted (positive and negative) by the project and how?

We have all seen that even small projects can create a ripple effect that touches many parts of an organization. All of the people touched by the project’s ripples are potential stakeholders. Identifying and categorizing the roles of various stakeholders is key to successful elicitation.

In the initial phases of business analysis, understanding who is affected by the project will help you refine the scope of the solution and build your core team of stakeholders.

Asking this question throughout the project lifecycle will also help you:

  • Identify new stakeholders
  • Identify and mitigate risks/constraints
  • Redefine needs or identify new needs
  • Elaborate requirements
  • Prioritize requirements

 

Advertisement

 

4. What would happen if we don’t change the way things are done today?

Use this question as an alternative to: “Why are we doing this project?” or “Why is this project important?”

As you may know, I love the question “Why?” but I hate to use it. “Why” questions tend to put people in a defensive position and can inhibit open and honest communication.

Also, framing the discussion in terms of “no changes”, is essentially asking stakeholders to define the current state. However, this phrasing will limit the “as-is” discussion to the processes and events that need to change.

Stakeholders will help you understand the key opportunities, risks of dormancy, the benefits of change — all-important inputs for successful elicitation.

 

5. What other changes are happening within the organization that may impact this project?

Most organizations function in a state of constant change. To avoid being blindsided, find stakeholders that understand how new strategies, policies, regulations, processes, and technology, might impact our projects.

Many project teams tend to isolate themselves within the silo of their business unit—often in an effort to stay focused. However, too much isolation can lead to missed opportunities for:

  • Collaboration
  • Integration
  • Sharing of best practices

Keeping attuned to organizational changes can help to:

  • Mitigate risks
  • Estimate project deliverable dates
  • Manage scope
  • Identify constraints
  • Understand interdependencies

 

6. How would you describe the process?

This is really a technique, with multiple questions, that I use frequently with SMEs in one-on-one interviews or in small groups. This technique is most effective when delving into the details of specific processes or events. Here’s what I do:

  1. I ask the SME/s to describe the process for me.
  2. Then, I draw the process out with them—on notebook paper, presentation paper, whiteboard, or using software.
  3. As they explain the process I ask, “What parts of the process would you improve and why?”
  4. I also ask, “What ideas do you and your teammates talk about as ways to improve the process?”

At the end of this exercise, I leave the room with a validated visual of the current state of the process and a list of opportunities to add value to the organization.

Let me know if these questions will help you or share your favorite elicitation questions below.

 

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

Written by Angela Wick on . Posted in Articles. 1 Comment on 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?

Advertisement

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

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

Written by Angela Wick on . Posted in Articles. 2 Comments on 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!

Advertisement

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

Written by Angela Wick on . Posted in Articles. 1 Comment on 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!

Advertisement

  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

Written by Angela Wick on . Posted in Articles. 1 Comment on 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
Advertisement

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!