Author: Angela Wick

User Stories: Your First Step Should Always Be Back

Written by Angela Wick on May 24, 2018. Posted in Articles.

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.

Help! I don’t have time to do requirements right!

Written by Angela Wick on March 27, 2018. Posted in Articles.

It seems each year it gets worse and worse—BAs have WAY too much to do! They can’t say no and can’t ask leaders to slow down the flow of requirements work.

The backlog grows bigger and bigger, and teams get further behind every day. It’s impossible to catch up.

I am going to write something that might shock you or might make you upset. It may also be a welcome confirmation.

YOU ARE PROBABLY DOING TOO MUCH – TOO MUCH OF THE WRONG THINGS!

Yes, I mean it. Most teams, when I really dig into their work and the dynamics of all the work on their plate, are doing too much.

Too much in terms of:

Too much detail in their requirements, usually technical details for pages and pages; when they need to focus on user goals, decompositions, rules, and data.
Too much scope, yep… most solutions need far less scope than we actually implement.
Too much work, most of the requests that come in don’t NEED to be done, and most are not as urgent as we are led to believe.

Here’s how it typically happens—WARNING—get ready for the vicious, head-spinning cycle…

Requests come in from business/operations teams, and they are simply that, requests. Teams that simply fulfill the requests, without analyzing them, end up missing pieces that trickle in as 5 more requests later. The snowball of craziness continues creating an ever-growing backlog of what seems like endless requests. It gets worse when the team and BAs work to write “tech specs” for each request, the team looks at tech specs and judges if it is feasible, not if it should be done. And, now no one is questioning the user point of view or the “WHY” part of the requests. Everyone is in “execute” mode.

Now back up…what if we asked the right questions before we start executing the “requested” technology update? Would our requestors have the answers? In most organizations with giant backlogs, the people making requests struggle to answer very important questions like:

What business problem we are trying to solve?
What does success look like?
What would happen if we don’t do it?
Who will be impacted by the request?
What is the end-user’s goal?

When our requestors can’t provide confident, meaningful, value-grounded answers to these questions, we have 2 choices:

Choice 1) We ignore the fact that the business case is murky. We tell ourselves the requestor knows what they need and it will be faster and more successful to just get ‘er done without asking questions.

Choice 2) We stop, think about it, formulate some good questions, identify the right person to ask the big questions, and have the conversation.

If you go down the path of choice 1, you are working too hard and not getting enough done. You are clearing requests, but nothing really gets DONE. Without fully understanding business and user needs, you are generating lots of rework. Repeatedly choosing this path makes your backlog grow exponentially and creates the vicious, head-spinning cycle that puts you in a constant state of fire-fighting.

If you so bravely take choice 2, congratulations! You are on your way to working less and getting more done. This is how we influence without authority! You’ll get half (hopefully more) of the work paused until there is a compelling reason to work on it and it can be defined in a way that will not cause rework later.

I have heard many say, “Oh I can’t do that, my leaders tell me just to get it done! If I ask too many questions, they will feel like we are stalling or going backward. They will get even more frustrated.”

Let’s talk about that for a minute. I think we have a great misunderstanding about what “get it done” means. When BAs hear “get it done,” they tend to think about how fast they can get requirements to developers. They reduce or even skip the elicitation and analysis work.

But when I talk to leaders, their definition of “get it done” is more like “get it done right” or “move our organization forward.” Leaders tell me they wish their BAs would ask better questions and work on the right stuff. They wish BAs would analyze and build relationships that influence others to carefully select (with a clear set of value- and user-driven requirements) which items are the most important.

This is an acquired skill that can’t be learned overnight! You can’t do it with a template. You can’t do it with edicts or procedures. It requires focus—concentrated focus to get the right conversations going.

But it is well worth it. It will make BA work fun again!

3 Things for Business Analysis Professionals to Focus on in 2018

Written by Angela Wick on February 6, 2018. Posted in Articles.

As we settle into 2018, the pressure to quickly deliver innovative products and solutions continues to increase.

We need to speed up the delivery process in a way that is responsive to rapidly evolving technology and ever-changing user needs and expectations. All too often, our teams end up rapidly delivering, but not getting the expected outcomes from a user and customer point of view.
This need for a responsive delivery approach will inspire many BAs and organizations to focus on these three goals in 2018:

1) Increase knowledge and awareness of new technologies and how they can improve the customer’s experience.

As organizations wrapped up 2017 and set refined priorities for 2018, one of the most common things I am seeing in portfolios and spending is a shift to artificial intelligence capabilities.

If you think your industry isn’t impacted by all of this, think again! Artificial intelligence, machine learning and robotics are already part of our daily lives—consider the fraud alert you receive when someone makes an unusual purchase on your credit card, the map app that suggests a faster route for your commute, or the ever-improving spam filter in your email.

If these technologies haven’t appeared in your project work yet, they will soon, and likely this year! Your customers and users will start asking for these advances soon, if not already. So, get ready to respond by increasing your awareness of how these technologies might influence your work.

For BAs, this means new customer interactions, new business models and new business processes that will replace existing processes that we thought were working fine. It also means helping our business stakeholders think differently about their own requirements and helping them understand the latest capabilities. Think about how these capabilities could provide a better solution than what a stakeholder may be asking for. They may be providing requirements that are using outdated technologies and there may be AI capabilities that better align to providing the user a better experience while helping the organization with their strategic agenda. I am betting our backlogs are full of requests that could be re-imagined and strategic!

BAs who are ready will have a ton of fun on these projects. BAs that are not ready might be left behind.

What can you do to get ahead? Make time to learn about AI capabilities. How can these capabilities help your customers meet their goals faster and improve customer interactions with your organization?

2) Define smaller increments to experiment or get feedback.

In addition to being responsive to new technology, effective teams need to be hyper-focused on their backlog management processes.

BAs and product owners are often in the driver’s seat when defining and prioritizing the backlog. They should consider the size, scope and value of each item. Each increment should also be an opportunity to experiment or get feedback from stakeholders and/or end users.

Feedback loops are king, and we need to get feedback FAST in today’s business environment. Organizations that do this well learn faster and please customers at a faster rate which is critical to success in fast-paced, complex and ambiguous environments.

If your team is struggling with backlog management, consider these tips:

Backlog items should express the WHO, WHAT, and WHY, in terms that the end customer understands and can be prioritized by business leaders.
Make sure the backlog is not just something the technical team is managing; it needs to be aligned with the business. The right business drivers should guide the backlog prioritization.
Backlog items should be “feedbackable.” When you deliver the item, will your users or stakeholders be able be able to see or experience the change and provide feedback?
Slicing backlog items does not mean dividing it up into tasks, components, or technical design details! Instead, slice by decomposing the item into smaller, but still user-valued pieces. Recently this is my favorite thing to help teams with, there is so much value in slicing backlog items strategically!

3) Collaborate deeper and just in time.

Another way be more responsive to stakeholders and end users, is to explore the quality and timing of collaboration. Teams that actively collaborate with their stakeholders deliver better products and solutions.

So BAs, your call to action is to ramp up your collaborative games skills. Both remote and face-to-face elicitation sessions should include facilitation techniques that deepen the discovery and learning cycles. Effective collaboration helps attendees move from good ideas to great ideas and from wishy-washy decisions to confident decisions.

But timing is important too. Defining too many details too soon, results in lengthy backlogs. If an item has been on your backlog for a few months (or years, uh oh!), it’s likely your assumptions/shared understandings are out of date, and a more advanced and innovative solution is needed to compete and please customers.

You can prevent rework and be more responsive to change by collaborating at a high level initially and defining details as close to delivery as possible.

Every team will deliver better solutions faster, when they stay on top of technology trends and refine their delivery processes to get immediate feedback from stakeholders and end users. It’s this responsive approach that will continue to delight your customers and give your organization a competitive edge in 2018.

What does the Thomas Fire in California have to do with Business Analysis?

Written by Angela Wick on January 2, 2018. Posted in Articles.

Being a bit of a BA nerd, I see connections to business analysis everywhere.

Life delivers endless examples, analogies and metaphors to give me new perspectives on the BA role.

As some of you know, I recently moved to southern California and the Thomas Fire has delivered my latest life/BA lessons.

Before it’s contained, the Thomas Fire is expected to become the largest fire in California’s modern history. It’s been a major disruption to the lives and livelihood of thousands of people. Though I live a few blocks outside the mandatory evacuation zone, and was in a voluntary evacuation zone for days. The power/internet/phone outages, ash and smoke made the area uninhabitable. So, I packed up a few things, including my little dog and drove north without knowing when I will be able to return.

The uncertainty and anxiety I’ve experienced in the last few weeks, have given me a new level of empathy for all people in the midst of disruption. While most work-related chaos, complexity and change does not have life-threatening consequences, I can’t help but see parallels between the fire and business analysis. It’s not my intention to minimize the fire’s devastation by making these connections.

Instead, it’s just a way for me to find a few lessons in the ashes.

Sharing Stories

One of the most interesting aspects of the fire is the media coverage. Even in our live-streaming world, I’ve noticed national news about the fire is at least 12 hours old before it hits the airwaves. With only seconds or minutes to share information about the fire, the stories provide a very narrow slice of the big picture and often focus on the most dramatic outliers. Many common stories do not make their way into the report and there are so many untold stories.

Our requirements work often shares the same characteristics! While requirements documents or status reports give overall status, they are often outdated by the time they are written and leave many stories untold.

As a BA, it’s our job to delight our users. We can’t do that without gathering and sharing a broad range of stories in a timely manner. We look at user and stakeholder needs and work to bring requirements and design ideas to the team. When a ripple effect of change moves through our organization, untold stories become costly in terms of rework after implementation. We can all think of a project that was on time and on budget, but resulted in unhappy users!

Impact Iceberg

Officials reporting the impact of the Thomas Fire share new numbers every day—the acre count, the structures destroyed, the number of evacuees, fire fighter counts, etc. The numbers are staggering, but they’re just the tip of the impact iceberg. The fire has disrupted so many lives in so many ways—schools are closed for weeks, businesses are closed for days during their key season, the streets are filled with ash, crops have been destroyed. It will take months, maybe years, to understand the direct and indirect impacts.

How do you manage the impact iceberg in your organization? How do you get below the surface? Great BAs connect with user groups to understand their confusion and frustration. They get curious and keep asking questions until they understand the full impact. If we accept and manage issues without getting below the surface, then we often fix the wrong problem, because we don’t understand the root cause.

Challenge yourself to improve your impact analysis and help the team and stakeholders better prepare for disruption and change.

Playing Defense

Fire fighters spend most of their time playing defense. They defend lives and property. They use techniques and procedures to contain the fire until the fuel runs out.
In our project work, we often get stuck in “fire-fighting” mode. Gaps in requirements force us to play defense when we are working on bug fixes and enhancement requests. When BAs shift their focus to offense, they generate better requirements that minimize rework and delight users. Modern, collaborative requirements techniques generate meaningful conversations that produce better solutions.

Organizations that are ready to compete and serve customers shift BAs from defense to offense.

A proactive BA approach, minimizes the impact of disruption. Take some time today to think about the impact of your project on the various user groups. I find this impact analysis is often a missing link in our requirements practices and I hope my personal story this week helps show how much this matters!

PS-I returned home last night, and my house is still standing, but my Christmas gifts will be late and probably a little smoky.

Agile Requirements Documentation – What’s Really Needed?

Written by Angela Wick on November 1, 2017. Posted in Articles. 95 Comments on Agile Requirements Documentation – What’s Really Needed?

During agile training sessions, the most common question I get is, “Can you PLEASE just tell me what I need to document as an Agile BA?”

So, let’s clear up this up once and for all!

The answer is NOT simply user stories and acceptance criteria, or a traditional requirements document. Agile is just not that simple. This answer would focus on the wrong thing—output. Instead of focusing on output, it’s the outcome and the path you take to get to the outcome and outputs that’s important.

The reality is, your job as a BA isn’t to document, and it never has been! Seriously. Even when doing waterfall or traditional approaches for requirements, the BA role is about facilitating decision making and facilitating future state discovery. Documentation is the output of all of this. Yes, documenting is part of the job, but it’s not the goal of the business analyst role, no matter what approach the team is using.

Start with the why.

I am not a “no documentation” zealot, but I am passionate about ensuring that what we create is valuable. Let’s ask ourselves two questions about the documents we create: “What is the purpose of the document and why is the organization willing to pay for it to be created?”

Requirements-related documents cost organizations lots of money, so we need to be able to answer these questions to get the right content documented. We want to avoid wasteful documentation as well as avoid the endless spin created by team dynamics that need a memory of what was discussed already.

When teams transition to agile, they often try to make a concentrated effort to look at documenting less; and this is a good thing to evaluate in the spirit of cutting out waste and focusing on value. When teams are going through this I often see a lot of wasteful documentation teams say THEY MUST have.

Here are the arguments I frequently hear for excessive documenting on agile teams:

My developers won’t start until its documented in this detail.
The QA/Testing team requires this much documentation.
We send the document offshore, so it must be a detailed document.
We are working with vendors so contractually we need to send them a document of detailed requirements for the whole project.
We are doing the development in an agile way, but not requirements too.
We need the requirements documented for training purposes.
We need the document to remember what we are working on.
We need the document for compliance.

I will provide my perspective on these arguments, but first we need to cover three important pieces of a healthy agile mindset and environment.

Apply agile principles and working memory concepts.

An agile approach enables teams to document less and increase speed while reducing costs. Here are the three agile principles that help teams reduce documentation:

Limited WIP (work in progress)
Small cross-functional teams, where hand offs are minimized to complete the work
Co-located teams (It’s possible to be agile with distributed teams, if teams leverage the facilitation skills, techniques and tools needed to make this work.)

It all comes down to “working memory” and leveraging the working memory of the team to reduce the dependence on documentation.

When a team has Limited WIP, they only work on one or a few things at once. There is less to remember because there aren’t days or weeks between discussions while you work through dozens of topics. With this intense focus, a small cross-functional, co-located agile team has enough working memory capacity to track details with minimal documentation. When a team is leveraging these principles, it feels strange and wasteful to stop and document unless the team agrees it is needed to help them move forward.

Working memory is a key to the puzzle and working memory is maximized when there is limited WIP, small teams and co-located teams. If your organization compromises on any of these, then the working memory of everyone is compromised. Work slows down while teams document to help them remember as they switch between too much work in progress.

What should be documented?

Documentation in agile is “living” and should be updated as the team need to update it. Think of it as a living asset the team uses that grows, gets pruned, gets trimmed and grows some more.

A small, cross-functional team with limited WIP, should document the following:

Product Vision: The team needs a shared understanding and reminders of the direction they are going. It should be visible too all so that it is pointed to and discussed daily as the details emerge.
Product Roadmap: The team needs a visual representation of the direction they are headed to achieve the vision and desired outcomes. And, it gets updated regularly!
User Story Map: The team needs to see the big picture of the user stories from a user journey perspective—to see the forest through the trees of the user stories of a product. And, it gets updated regularly!
Placeholder for the Conversation: The team needs a way to capture past conversations or hold a place for future conversations. This usually includes user stories and some acceptance criteria.
Analysis Assets: The team needs to SEE conceptual and analytical models. These visuals help the team remember the big picture of the process, people, technology, rules and data pieces of the project. These are things like: story maps, scope diagrams, decision tables, ecosystem maps, data flow diagrams, etc. These are visual—hung on the wall so teams can quickly jump up and huddle to discuss how a user story relates to all of them, and they are updated as often as needed.

Remember to keep documentation as simple as possible. Choose a format and level of detail that allows change and delivers just enough value to keep the team moving forward in the right direction.

What about compliance, QA, vendors, offshore teams, training, etc.?

OK, back to all those arguments teams use to rationalize excessive documentation. When you focus on limited WIP and small, cross-functional, co-located teams, these are the agile-minded responses.

My developers won’t start until its documented.
- They should be part of the team, not a hand off
- The entire team needs a shared, limited and focused WIP
- The Product Owner and team need to see working product quick to give feedback to the developers, the more feedback loops, the better the product will be.
- A quality conversation about a small piece of work is enough to get started, if not, then the conversation may not be on track.
The QA/Testing team requires the document.
- They should be part of the team, not a hand off
- The entire team needs a shared, limited and focused WIP
- A quality conversation about a small piece of work is enough to get started, if not, then the conversation may not be on track
We send the document offshore, so it must be a detailed document.
- They should be part of the team, not a hand off
- The entire team needs a shared, limited and focused WIP
- A quality conversation about a small piece of work is enough to get started, if not, then the conversation may not be on track
We are working with vendors so contractually we need to send them a document.
- They should be part of the team, as needed to account for a more collaborative work style rather than hand offs
- Limit the WIP you give them, force them to work on just a little at a time and allow you to provide frequent feedback.
We are doing the development in an agile way, but not requirements.
- If requirements are not agile too, then how to we know we are building the right thing?
- Requirements not being agile compromises actual agility to change priorities quickly and take in requirements change for strategic advantage.
- Just in time requirements for the most important pieces with a limited WIP maximizes the ability for the organization to learn and change quickly without leaving work mid-progress or waiting for a large piece of work to complete to get to the hottest priority.
We need the requirements documented for Training purposes.
- The solution design is flawed if you need to train your users on how to use the application. Technology of today and tomorrow will no longer support this type of design.
- There are faster ways to create training documentation than using spec documents. Work as a team with a limited WIP to get the inputs to the trainers that they need.
• We need the document to remember what we are working on.
- Too much WIP! Limit WIP and see less documenting needed.
- Focus on finishing one or few pieces at a time, not on starting more work.
We need the document for compliance.
- Most teams are documenting too much for compliance compared to what compliance actually requires.
- If you really dig into what compliance requires, lightweight documentation usually works just fine
- Also consider documenting what was built rather than before it is built so that the team does not have to do rework when things change.

Essentially, I’m asking you to adopt an agile mindset and advocate for limited WIP and smaller teams that reduce the need for documentation, reduce costs and accelerate product/solution delivery.

If your organization has compromised these principles, then working memory challenges are likely driving your teams to document more. That is okay, as long as the team and organization realizes the value of the document and is consciously choosing to slow down outcomes and results due to the choice of compromising the agile values.

Remember that your role as an agile business analyst is not about documentation. It’s about facilitating good and timely decisions, and guiding stakeholders to discover a future state that delights the end user.