Author: Angela Wick

Customer Obsession – You Better Have It!

Written by Angela Wick on September 26, 2017. Posted in Articles. 1 Comment on Customer Obsession – You Better Have It!

Everything you do impacts the end customer. Yes! Even if your project doesn’t seem to touch the end customer, there’s always a connection.

Great BAs understand this and help their stakeholders discover the customer connections for every product, project, enhancement, feature and even for simple bug fixes—that’s customer obsession.

As I think about the early days of my BA career, we had this customer obsession! Unfortunately, it’s kind of a lost art these days. The customer seems to lag in the race to deliver “on time and on budget” or gets silenced as we debate methodology or best practices.

There is a technique that comes to mind (from these olden days of customer obsession) that I don’t hear about much anymore. I think it’s ready for a comeback.

Anyone remember using the TouchPoint Matrix?

Shout out to BobTheBA – Bob, I remember we talked about this years ago, so I’m bringing it back to the table for a broader dialog! With a few updates, this dusty old tool would be quite useful for a variety of projects including those tangled in agile and digital transformations.

So, let’s take an imaginary journey…what if…what if…you started your project with a Customer Touchpoint Analysis? You would gather your stakeholders together to explore the value streams and processes that your customers use when interacting with the product, service, application or process. How would that change course of the project? What if everything you did with requirements, user stories, and the like was anchored and centered in the end-customer point of view?

Our leaders are begging us to be more customer centric. Human-centered approaches like design thinking are finally getting traction and gaining popularity. How can BAs expand these approaches to make sure that we don’t lose the intent of a great customer experience in the detailed requirements and the build of the solution?

For example: If you are working on a billing system, the customer’s bill/invoice is an obvious touchpoint. But there are so many more! Your touchpoint analysis would dive into how the bill/invoice experience impacts the customer overall:

• What actions did the customer take before or after getting that bill?
• What interactions did the organization have with the customer before and after that bill?
• What method/platform did the customer or the organization use to complete the interaction? Emails, text messages, phone conversations, web/online interactions, in person?
• Do the interactions across platforms align?

The customer doesn’t see or care about the various technical platforms, they can are all the touchpoints that they have had with you as an organization. Do they make sense? I can say for sure that many encounters with organizations I have just aren’t making sense, no one seems to be looking at my experience holistically.

I recently interacted with a company that needed a dose of customer obsession and a touchpoint analysis. I contacted the company to cancel my service. So a few days later, I was very surprised when I received a phone call that someone was at my house to provide a fix for a reported problem . To top it off, I was billed for the service too, yes after I had cancelled. Touchpoint gone wrong! Hours of calls to fix the seemingly simple issue indicated many more touch points gone wrong. It’s possible this company built and enhanced its systems on schedule, within cost and within scope, but forgot about the customer. Did anyone look at the customer experience overall to see that none of the touchpoints made sense when all linked together from a customer point of view?

How are your touchpoints with customers aligning? If you work in only one area or with one system, chances are your touchpoints are not aligned and the customer is frustrated. We’ve all had a call center agent ask us for information we’ve already entered into the keypad. Frustrating!

My favorite touchpoint-gone-wrong experience this week was with an airline. They informed me, via a mobile app message, that I was eligible to upgrade to first class for an upcoming flight. I’m thinking, “Awesome—free food and more elbow room!” The app tells me to “tap to confirm” and then assigns me a seat in first class. Great, but—when asked to check in online for the flight, I am forced to pay for the upgrade, with no option to turn down the upgrade and take back my original coach seat!

I know we have all experienced this lack of alignment between systems and processes. Where is the BA role in this? Everywhere!

As customers, our expectations are increasingly becoming more refined and we no longer accept these frustrating and inappropriate experiences. We start to lose trust in the organization and look for other options—companies that deliver better experiences.

As BAs, we’re responsible for helping our stakeholders discover and explore customer touchpoints. It’s our job to be obsessed with our customers and make recommendations to improve the customer experience.

Are you ready to take back touchpoint analysis?

Planning for Requirements in Agile – How is it different from Waterfall?

Written by Angela Wick on September 12, 2017. Posted in Articles. 1 Comment on Planning for Requirements in Agile – How is it different from Waterfall?

Many teams struggle with their requirements approach, but it’s especially challenging for teams transitioning from waterfall to agile.

If the team neglected requirements planning in waterfall, they assume agile requires even less planning. This leads to even worse results than their traditional approach, and the agile transition fails.

If the team planned well in waterfall, then they struggle with agile’s iterations and timelines. They aren’t sure how to plan requirements without structured waterfall phases. Lacking an alternative, most teams default to their old approach by focusing on document deliverables, activities and time needed from stakeholders. But that document deliverable-based approach, conflicts strongly with agile values. Agile values focus on deliverables being defined as business outcomes and working software, rather than document based deliverables.

Agile calls business analysts to shift their thinking about requirements planning. Instead of focusing on document deliverables, agile BAs plan their approach by defining and prioritizing increments of value; or increments that move outcomes. They determine which increments provide the most value and in what order. Increments of value come in many shapes and sizes including things like fixing a defect, running an experiment, building a slice of a prototype, or a user story at various levels of detail.

In both approaches, best practices call for multiple levels of planning where teams decompose requirements from a high level to detailed levels. Since many of you are familiar with the BABOK v3, let’s use it as our guide for planning. Here’s how the BABOK’s BA planning tasks manifest themselves in an agile approach:

Plan Business Analysis Approach: choosing methodology, activities, tasks and deliverables.

This is where agile values can really shine! Not all projects fit the agile approach, but increasing complexity, ambiguity, and market volatility push teams to use an agile approach more frequently.

When using agile, your BA work focuses continually on priorities and backlog refinement. This is not a task or phase that is “one and done”—planning is ongoing. In fact, agile teams and BAs plan to re-plan!

Agile BAs evaluate priorities holistically. They look at the priorities and ask themselves:

How do these priorities align to delight the end user?
How do these priorities align with strategic objectives?
Can these priorities be chunked into smaller increments of value?
Does the entire feature need to be built or can the team define incremental and usable versions of the feature?
Where does each new increment rank in priority compared to the other items on the backlog?

Agile planning is about getting quick feedback from users to inform decisions on the next level of planning and establish priorities. Agile BAs work closely with the product owner to track the visions and direction of the solution, to understand high level priorities, and to break down priorities into smaller pieces that can be delivered quickly to get user feedback.

Plan Stakeholder Engagement: identifying and collaborating with stakeholders.

Here BAs work closely with the product owner to determine who the various stakeholders are and how the team will interact with them.

Using the product vision, roadmap and backlog as a guide, BAs can determine:

who the important stakeholders are
when we expect to need time from them
how much time we need to work with them on story refinement
how and when to get feedback on the solution as it gets built

When requirements planning is ongoing, BAs continuously work on the backlog. They understand what is in the short-, mid- and long-term so they can anticipate when stakeholders are needed. Some stakeholders will interact regularly and some less frequently with an agile team.

Plan Business Analysis Governance: making good, consistent decisions while managing resources and risks.

When teams truly embrace the agile principles, there is actually more governance than you see in many waterfall or traditional approaches.

Why is this? Because there is a clear decision-making process and a clear role accountable for the decisions. In agile business analysis, this means knowing who the product owner is, and working closely with them as the decision maker. It entails helping the product owner understand when certain decisions are critical and ensuring they have the needed information to make them.

Plan Business Analysis Information Management: how to capture, store and integrate information gathered by business analysts.

Traditional projects teams capture and store requirements in documents and requirements tools. Agile teams can also use tools, but they tend to rely more on whiteboards, walls, flipcharts and sticky notes to capture and store requirements. With agile teams there is a lot less work in progress, so there is less to manage at a detailed documentation level.

The key in agile is for everyone to understand the big picture vision of where the solution is headed, and the details of what is currently being worked on. Agile calls us to think about what we are documenting. BAs on agile teams always ask themselves:

Is this documentation valuable and useful?
Who does this documentation provide value to?
When is the documentation needed?
How long will the documentation provide value?

One thing I commonly see teams concerned about is the life of the requirements. They hesitate to move away from big requirements documents because flip charts and sticky notes don’t seem like legitimate artifacts for future reference and support. I struggle with this because I have never seen it to be a good practice to use requirements documents as support documentation. This puts an undue burden on the requirements process and slows it down. Documentation of what was built and how it will be used is not the same as requirements. These are different artifacts and different purposes.

Identify Business Analysis Performance Improvements: managing and monitoring business analysis work for continuous improvement.

This is the “monitoring task” in the BABOK rather than a planning task. Agile teams use retrospectives to improve performance. The retrospectives facilitate continuous improvements in:

team processes
team collaboration
the quality of team and individual work

Whether you use the BABOK as a guide for requirements planning or take your own approach, remember that balance is the key. Avoid diving recklessly into the action without a plan, but don’t let planning be a burden that prevents progress. Whether your team is agile or traditional, find the balance that consistently and efficiently delivers value to your end users

The Shift to Modern Requirements

Written by Angela Wick on July 25, 2017. Posted in Articles.

I’ve been on the road quite a bit lately, and part of my travels include delivering conference presentations about modernizing requirements.

The presentations hit home with those who are feeling the stress of increasing speed, complexity, ambiguity and change. Trends and transformations related to agile, artificial intelligence, machine learning, robotics, etc., are putting immense pressure on business analysts to build better requirements, FASTER!

This pressure is compounded by the perception that project failure is due, in large part, to inaccurate requirements gathering (2017 PMI Pulse of the Profession Survey). Is this perception a reality? Do we need to adapt our requirements approach?

Shifting to modern requirements practices does not require a major overhaul. Instead, modern requirements are the same best practices shifted slightly, with a change in mindset. Consider these three questions that highlight the differences between “old-school” and modern requirements:

Do you spend more time preparing documents or preparing techniques?

I remember the early days of my business analyst career when my requirements approach was a list of document templates. The same templates needed to be completed, reviewed and approved for every project. My job was to fill in the templates. There was little or no coaching on how to get the information needed for the templates.

Fast forward 15+ years. Now techniques drive my requirements approach. I carefully consider which technique or set of techniques will help me get stakeholders talking, thinking and collaborating. I choose techniques that will create a shared understanding that gives each stakeholder a clear picture of context, user needs, and value.

Then, I only document what is needed to remember the conversation and capture the shared understandings created by the conversation. When teams break their work into small chunks of value and working closely together, then less documentation is needed. Working with small chunks of value is why agile teams tend to document less. Agile teams have a small “work in progress” and small number team members so documenting can seem like a waste to them.

Many are concerned about documenting for audit, compliance, support, etc.—and this is valid. However, I would also argue that the requirements documentation shouldn’t be a document of what was built, rather what the user needs. There should be other mechanisms in place to document what was built.
I am not advocating for no documentation—I am simply putting out there that I believe too many teams are documenting far too much at the cost of missing out on using that time for other strategic projects and work.

Modern business analysts don’t spend time on documentation unless it provides value to the team. Instead, they apply facilitation techniques to help the team learn, experiment and create shared understanding. Modern Business Analysts strategically plan how they are going to use techniques to move the team through the evolution of the requirements from a high level to a detailed level.

This technique-driven approach makes requirements cognitively easy for the team and stakeholders. They have a deep understanding of how their work fits in the big picture. A technique driven approach can more quickly elicit and obtain more accurate requirements.

What do meetings look like?

Meetings look a lot different when a Business Analyst shifts to a technique-driven requirements approach. High impact collaboration becomes the goal of every technique they use. Meetings focus on a high-quality conversation over reviewing documentation. The high-quality conversation comes from high impact collaboration.

High impact collaboration helps BAs and stakeholders get to shared understanding faster. The quality of requirements also improves, because we get beyond stated requirements to the real needs of users.

Here is a comparison of low impact and high impact communication methods:

Low Impact Collaboration	High Impact Collaboration
Reviewing text-based documents and requirements in tools	Co-creating visuals, lightweight documentation
Audio only conference calls	Face-to-face (video), digital whiteboard collaboration, other online collaboration tools
Sitting at a conference room table	Drawing on whiteboards, working with sticky notes on walls, building prototypes, brainwriting, experiments, etc.
Email chains or instant messenger feeds or slack channels.	Small group huddles (face-to-face or video conference)

How are requirements organized?

A value mindset dramatically improves the quality of the modern business analyst’s requirements. The value mindset calls BAs to organize requirements by value stream and value increment, not by system area. The value mindset puts user and organizational value ahead of the team’s needs.

BAs help their teams think like users (outside in) instead of thinking like techies and analysts (inside out). Great BAs go beyond requirements and inspire the team to organize backlogs, features, needs, issue lists and even conversations by value.

This mindset change is the key to preventing failure. Teams that focused on the user and organizational value avoid over or under engineering solutions. They prioritize what’s most important to the user, not what’s easiest for the team. This gets users what they want faster and keeps the users on board for future iterations.

When business analysts modernize their requirements, teams reduce waste. They minimize time and money spent on tasks, deliverables, features, solutions, and products that do not provide value.

Despite increasing change, complexity, and ambiguity, requirements can be done faster with better quality. When BAs use techniques that focus on value and create a culture of high impact collaboration, failure points surface faster and make addressing change less painful, with less impact on results, cost, and

schedule. In turn, modern requirements give project leaders confidence that their teams are focused on the RIGHT stuff—solutions that will deliver value to the users and the organization.

Survival Guide: Bouncing Back and Forth Between Agile AND Waterfall

Written by Angela Wick on June 8, 2017. Posted in Articles.

Are you bouncing back and forth between agile and waterfall? It’s quite common these days for Business Analysts to grapple with both agile and traditional approaches to requirements and development work.

This can be frustrating, and Business Analysts may feel like a ping pong ball, getting smacked back and forth between two different worlds.

Assuming this scenario is not going to change, Business Analysts need to find a way to reduce their frustration level and think about their work a little differently. It’s time to change up the game!

Have you ever heard a coach tell an athlete, “Be the ball.” I never understood this advice, but it doesn’t work for Business Analysts in our Agile/Waterfall ping-pong scenario. So, let’s change perspectives. Instead of getting smacked around by multiple methodologies, Business Analysts can take charge of their methodologies. It just takes a shift in thinking, like this:

Now the Business Analysts are in the power position, taking charge of how to approach each incoming ping pong ball. Some might require finesse, some might require backspin, some might require a long volley, and we might even duck and let some fly right past us.

It’s the same for Business Analysts moving between agile and traditional projects—they modify their approach to match the work that is flying at them. The best way to survive and do consistently excellent requirements work is to consider what stays the same and what’s different.

To explore the similarities and differences, let’s see what happens when an agile ping pong ball and a waterfall ping pong ball collide. Hello, ping pong Venn diagram!

Let’s start with what’s different—team structures and team operations/procedures. In most cases, the structure of a traditional team looks a lot different than an agile team. A traditional team might have a defined hierarchy, where an agile structure might be flat, with several self-organized teams with loosely defined roles. The way the teams operate could be quite different too including the way the team collaborates, the timing and sequence of tasks, the process for reporting and measuring progress, etc.
BAs need to learn to roll with these differences, but luckily these differences don’t impact core Business Analysis work. It turns out the things that remain the same, in the center of our ping pong Venn, are the most important components of good requirements regardless of methodology. If Business Analysts focus their energy on these three areas, it will reduce the frustration of bouncing between Agile and traditional approaches.

Focus on the Customer

Both approaches demand we look at requirements from a customer point of view. The customer point of view carries most requirements and rarely fails us as a place to start requirements conversations. In both agile and traditional approaches, BAs are called to expand the definition of customer to include everyone who uses the solution internally and externally. BAs are also called to find innovative ways to identify and meet each customer’s rapidly changing needs.

Cultivate Conversations

Successful BAs in both agile and traditional environments use powerful conversations as the focus of their requirements process. Even in traditional/waterfall approaches, conversations are critical to getting to well-written requirements.

Powerful conversations take place with individuals or in groups and require a variety of elicitation techniques including brainstorming, games, models and visuals. Powerful conversations should be layered with whitespace—this means giving stakeholders time to process their thoughts internally before large group discussions.

Whether you are using an agile or traditional approach, cultivating conversations means dialog comes before requirements documentation. BAs let go of the temptation to hold a meeting to “review” a document or items in a tool before the team has a powerful and meaningful dialog. BAs who focus on conversations know that dialog before documentation speeds up the requirements process for both agile and traditional projects.

Avoid the HOW

Digging into the technical details, before the team understands customer needs, damages agile and traditional projects. So, let go of technical details. The BA role helps the technical team understand the needs and even collaborates on possible designs to meet the needs, but BAs should avoid the urge to tell the technical team exactly how to develop the solution.

Many BAs have knowledge of the technical details but realize this knowledge becomes outdated quickly. It can be tough to let go of knowledge, but remember, technical knowledge is not what makes BAs successful. Instead, focus on the user, goals, data, rules, and business process all with an eye on the future state. Don’t let your knowledge of the current or past keep you stuck there.

The truth is that BAs need to be versatile to survive! They need to be able to handle a wide variety of ping pong balls. This is not a new expectation. Successful BAs have always been able to operate in diverse environments. No teams or organizations work the same. Global teams, virtual teams, agile teams, hybrid teams, vendor teams and even internal teams choose different approaches to project work. Successful BAs stay focused on customers and conversations regardless of the methodology their team uses to deliver solutions.

Please leave your comments below.

4 Agile Metrics Every Business Analyst and Product Owner Should Care About

Written by Angela Wick on April 26, 2017. Posted in Articles.

It is true that “working software is the primary measure of progress” in Agile, but that is not our only measure. The Agile Principles also call us to reflect on how to become more effective.

As Business Analysts and Product Owners, we should care about metrics that provide value—that give us insights into our team’s ability to effectively and efficiently deliver working software that delights our end users and customers.

There are dozens of possibilities, but here are four of my favorites with a few thoughts on the value they bring to the Business Analyst and Product Owner roles.

Carry Over

Carry Over measures the amount of work pushed from one Sprint or iteration into the next. While this metric can shine a light on many team challenges, Business Analysts and Product Owners should be most concerned about “user story scope creep.”

Consistent Carry Over points to User Stories that are too big going into the Sprint or are growing in scope as the Sprint evolves. Either way, it means the stories were not analyzed and properly sliced before they entered the Sprint. This slows delivery dramatically as teams waste time analyzing, slicing and reprioritizing during the Sprint.

Smaller chunks of work improve the team’s ability to estimate accurately and deliver value without Carry Over. Look at your User Stories closely to determine if you are effectively slicing stories into small, independent increments of value. Analyze the story slices and break them down until each story is “finishable” within your standard iteration duration.

Also, before estimating, it helps to have the Product Owner, Business Analysts, Tech Lead and Quality Assurance meet to discuss each story. This ensures the right dialog to identify when a story is too big and at risk for Carry Over.

WIP – Work in Progress

WIP is a measure of how much work the team is doing at one time. The team’s WIP should be the least amount of work (or User Stories) that they can handle while staying busy, but not more than that! Any more will slow the team down by pushing out iteration delivery dates or creating more carry over.

Why is this important to Business Analysts and Product Owners (PO)? Because Product Owners own what gets put into the work queue and Business Analysts help the Product Owner define this. We are critical to defining the flow of work. This means Product Owners need to say “NO” to new work so the team can stay focused until they deliver their current iteration.

The team works together to define its WIP limits to maintain a consistent flow of work. The Product Owner and Business Analyst make sure that items are ready to flow into the team when the team is ready to pull more in. The goal here is to “stop starting and start finishing” work. You know your team has too much WIP when the team keeps starting new work rather than finishing what they have started.

Release Frequency

You might think of the Release Frequency metric as more management or technical in nature, but it is often a great indicator of the effectiveness of Business Analysis. The better Business Analysts and Product Owners are at defining small increments of value and minimum viable product then the more often teams can consider releasing.

There can be technical process challenges that impact release frequency, but the root-cause usually leads back to defining a releasable chunk of work that matters to the user. This requires Business Analysis! Business Analysts and Product Owners define the releases. They analyze processes, user needs, user experience and technology to slice User Stories into small, independent increments of value.

Number of Backlog Items NOT Done

This metric is about focusing on the future, rather than fixing the past. Many teams are dutifully focused on getting through the Backlog. They just assume it all needs to get done and think of it as a giant checklist.

Effective Business Analysts and Product Owners assume that 25-50% of the Backlog will not get done. (This percentage is even higher for some teams.) Business Analysts and Product Owners continually refine the Backlog to make sure the team is working on the most valuable, highest priority items that keep end users and the organization moving forward. This refinement often means removing things from the Backlog that don’t belong because they keep the product in the past vs. creating the future.

So, measure the number of things NOT done and see how much you are saving the organization by NOT doing things, and focusing on the future rather than the past!