The cornerstone of a user story is a single statement in the following syntax:

“As a [user], I can [do something] so that [perceived benefit].”

Discover the benefits of user stories and how they fit into the BA workflow by watching the video below.

Hi, I’m Laura Brandenburg from Bridging the Gap, and today we’re going to talk about user stories and how to write user stories and be really effective with this technique as an agile business analyst.

User stories are a way of capturing requirements that is commonly used on an agile software development team or a team using the agile methodology of some sort.

Benefits of User Stories

There are some really key benefits to managing requirements with user stories.

First of all, when you’re using user stories to manage your requirements, you’re often organizing all of those stories into the product backlog. That allows you to rank prioritize the requirements, which is a very agile focused technique, as opposed to like a big document where everything is “priority one.” That rank priority makes it incredibly clear which requirements are the most important and most valuable to the business. You, as the business analyst are focusing on the most important requirements and the development team is also focusing on the most important requirements.

And now the other piece that I really love about user stories is the very syntax of how they’re written, which we’re going to go through in just a minute here, links each functional requirement to the anticipated business benefit, and that makes it much more difficult to just sort of add in or sneak in requirements in a big document or even in a use case. I love use cases, and we’re going to talk about how to incorporate those into your user story development process a little bit at the end.

What I have found when I only write use cases is they can get a bit bloated with extra steps and alternate flows and all kinds of exceptions, and all of a sudden something that seemed really simple becomes really complex and that becomes very obvious when you are breaking down the requirements from a use case into user stories because then you have to prioritize each of those independently.

And then the final thing I really love about user stories is that they create this powerful link between your requirements work and your development work which helps us, again, guard against unnecessary scope creep, or projects that really become more intensive without actually creating more value. That’s a great position to be in as a business analyst, making sure you’re paying attention to value.

User Stories Defined

So what is a user story? The cornerstone of a user story is a single statement in the following syntax. As a user, I can do something so that whatever that perceived benefit is of that feature. And then you include whatever accompanying details or supplemental materials you need to make the user story clear and implementable.

Often these are detailed in acceptance criteria or the conditions the software must satisfy to be accepted by a user, a customer or a stakeholder.

An Example User Story

Let’s go ahead and look at an actual example, which I think will make this much clearer.

This is an example that we include with our use cases and wireframes module of The Business Analyst Blueprint training program®.

As you can see up here, the title for this is The Username Doesn’t Exist. This is a component of a bigger use case that would be logging into the system. That use case has multiple different features and exceptions and alternates. This is just one little piece of that. What happens if the user tries to log in and that username does not exist in the system? Up here we have a, as a user. I can be notified that the username I provided does not exist so that I can provide a different username or try to log in again.

Here we have our different acceptance criteria. They’re written in this given when/then format. So given this happens, then this happens. Given this happens, then this happens.

Now what we’ve also included here is a wireframe. And what I have found as a business analyst, it’s often really helpful to have not just the acceptance criteria detailed out in words, but to have some sort of supporting documentation. In this case, the wireframe made the most sense. Other times it might be a workflow diagram. It might be the use case that this user story is a part of. It might be a data model, if it’s data intensive. It could be a data dictionary or a glossary of terms, or an ERD, like a piece of the ERD. Those are all examples of what you could include as supporting documentation. In this case, we have a wireframe.

So that’s an important piece to keep in mind. There’s some specificity to user stories, like guidelines, and how to create them. But I think there’s also a lot of judgment as a business analyst of what actually is going to communicate these requirements in the most effective way to my software development community.

Wireframes are super common. Here’s a video explaining how to create a wireframe if you want more detail on this business analysis technique:

How User Stories Fit into the Business Analysis Workflow

I think another thing that we really need to keep our mind wrapped around is how these user stories fit into our workflow as business analyst.

One area that often gets overlooked in agile circles, even still today, is how the development of the user stories fits into a business analyst process framework.

If you aren’t familiar with what a business analysis process framework can look like, here’s a video tutorial on that:

Agile is a Software Development Process, Not a Business Analysis Process.

Agile is a software development process. It is not a business analysis process.

Most agile methodologies, whether they explicitly do this or not, there’s some sort of assumption built in that the details of what goes into a user story are fairly well known or easy to figure out, and just a matter of the business analyst sitting down with a user and really figuring that out and having one quick conversation with them.

The reality is that often as a business analyst:

• You need to be collaborating with multiple stakeholder groups to rank and prioritize and estimate those user stories.
• You might need to gather information from multiple different stakeholders groups to build out that acceptance criteria or to gain alignment on what the software actually needs to do.
• You might need to dig in and figure out what the business process is before you even start defining what those software requirements are.

There could be a lot of background kind of upfront work that even though we want to be more agile, we also want to be thinking things through.

As a business analyst, when I’m on an agile team, I’ve found it a good practice to work ahead at least by one or two sprints, and that’s if things are relatively simple.

If you’re dealing with something much more complex where there’s a big business process focus, you might need to work even further ahead than that kind of doing some of that business process work before you get into the sprint part of the development process.

What that means is that I’m always prioritizing the product backlog that will be developed in the next month or two. That gives me time to refine those requirements, to get all the necessary stakeholders on the same page about those requirements, and to detail out those acceptance criteria so when we go into sprint planning, I’m ready with the good draft of what the requirements are for this user story, and then we can have dialogue with the technical team. I can go back and clarify things if I need to or add to them or supplement them.

But I’m not doing the heavy lifting of getting all the stakeholders on the same page while the developers are trying to build that feature. I’ve done that before under the pressure of agile. What happened is we built one thing and had to change it and build it again and nobody was happy, especially me, especially the developers as well. .

When Focused on User Stories, It’s Easy to Lose Track of the Big Picture

The other thing I want to say is that when we are focused on these little user stories, especially like that example of “the username doesn’t exist,” it’s a little tiny piece of functionality. It is really easy to lose track of the big picture. And when you lose track of the big picture, it’s common to miss requirements because you’re focused on this one little piece. As a business analyst, you need other techniques to maintain a view of this big picture.

What we teach at business at Bridging the Gap is use cases because we find that use case thinking and the semantics and the logic of a use case helps business analysts uncover otherwise missed requirements. And if you are a great agile business analyst, you’re like, “Laura, I write user stories all the time. I don’t ever write use cases,” that is totally possible. I’ve done that too, but it’s because I had that use case thinking background in my head and I was thinking through the use cases, even though I wasn’t writing the use cases and I was using that use case thinking to hold together and think through how all these user stories fit together.

And so it might be that use cases or use case thinking has become so intuitive to you by now that you don’t actually have to write the use cases if you’re new and struggling with how to make sense of this big glob of user stories that you might have on your plate. You might want to actually put them together into a use case or a business process model, or a process map, or a workflow diagram to help you think through that bigger picture view before you dive into each individual story.

Download our Use Case Template

If you’d like to go further on the use cases specifically, I do have a free template for you that you can use to walk through with some guiding text. It’s absolutely free. You can just use that link below.

And again, that technique is going to help you avoid missed requirements and think through the big picture of how your user stories fit together.

Again, user stories are an incredibly important technique. We need to know them as business analysts, especially if we’re working on agile teams. Mastering use case thinking is going to make you a stronger business analyst who can weave those user stories together in a meaningful way to ensure that the team delivers a solution that’s truly valuable to the business.

Again, my use case template is available through that link below. We’d love to help you take the next step with this skill in your career.

I’m Laura Brandenburg with Bridging the Gap and we build our profession one business analyst at a time. Success starts with you. Thanks for being here.

<<Click here to download free template>>

Use Cases Are One Way to Analyze the Functional Requirements

If you are looking for more guidance on use cases, here’s a video tutorial to go through:

Use Cases and User Stories Can Work Together

You can also learn about how use cases and user stories can work together here:

Nothing could be further from the truth. Here’s exactly why agile teams need business analysts.

For those who like to read instead of watch, here’s the full text of the video:

Many business analysts feel like their role is not needed in agile. We hear that agile teams, they don’t want requirements. Then we assume that they don’t want us as business analysts. Nothing could be further from the truth.

I’m Laura Brandenburg. I’m the creator of Bridging the Gap. Today, we’re going to talk about why business analysts are absolutely essential to agile teams.

Recently, one of our community members commented that in his early meetings with agile practitioners, he felt like something was off, something was missing. He wasn’t quite sure what it was. After going through our free training, he discovered it was the business analysis part of the process.

Where did those requirements come from for those users come from for those user stories?  What was that working software supposed to do?  That information comes from us, the business analysts.

One of my mantras is that on every successful project, you’ll find a business analyst. That’s true, even if they don’t have the title of Business Analyst.

Agile, as wonderful as it is, it’s not a business analysis process. It’s a way of developing and delivering valuable working software to the business. Agile teams, they need business analysts.

• They need us to discover what the business users need and want and determine what changes will have the most value to the business, so we can effectively use agile software development practices to deliver it with maximum efficiency.
• They need us to collaborate with business users and sponsors across the organization, and to gain alignment on what is wanted and needed and ensure that those items in the product backlog and those details in the user stories represent true value to the business.
• They need us to take a holistic view of the product backlog and find all those inner related requirements and inter-dependencies and make sure that the pieces of working software delivered are, again, going to deliver value in the context of that end-to-end business process.
• On that note, they need us to discover and analyze what those business processes are and help the business users implement the changes necessary to fully leverage that new software. That is supposed to make their jobs easier.
• Last, but not least, they need us to keep the backlog well organized. To keep it groomed and prioritized, and add those estimates and filter through it, remove things, and add things so that the team can easily see what needs to be done in the next sprint, and the sprint after that.

Agile practices and business analysis actually deliver tremendous value to organizations when they are leveraged effectively together. Let’s stop questioning why we need business analysts in agile, and let’s start looking at how we can all work together to achieve the most possible value for our organizations. Things will be so much easier when we’re all working together as a team.

I do have some more resources for you on how to be an agile business analyst. There should be a link to this video or go to bridgingthegap.com/agile-business-analyst. I’ve laid out exactly how to apply the business analysis process we teach at Bridging the Gap, and in agile software development environments. Be sure to check that out.

I challenge you. What will do to be a better partner to your agile team today?  How will you help your organization be more effective?  How can you leverage the combination of agile practices and business analysis to deliver even more value more quickly to your business community?

Leave me a comment below. I’d love to hear about your success.

Again, I’m Laura Brandenburg from Bridging the Gap. Thanks for listening.

The Agile Business Analyst: 4 Crucial Strategies for Success

To follow-up from this video, let’s look at 4 crucial strategies for applying the business analysis process in an agile environment.

Agile Business Analyst Strategy #1 – Resist the Temptation to Skip Steps 1-3

Most agile practices make certain assumptions about what information the business stakeholders can provide and how quickly they can make decisions. These assumptions are valid inside steps 5-7 of the business analysis process. But steps 1-3 (Getting Oriented, Discovering the Primary Business Objectives, and Defining Scope) are still important.

As an agile business analyst, these decisions you help stakeholders make in these steps provide the foundation you need to effectively and iteratively deliver the requirements in step 5.

• The current capabilities assessment completed in step 1 will help you and your team discover simple, quick wins that can add value quickly.
• The business objectives discovered in step 2 will help your team prioritize the product backlog to put the highest value items first.
• The scope decisions made in step 3 will help your team stay on track and make meaningful adjustments to expectations.

Most often, these steps will start before the “agile” part of the project and it’s prudent to make time for them even as an agile business analyst.

(By the way, we cover each of the 8 steps of the business analysis process in our BA Essentials Master Class.)

Agile Business Strategy #2 – Create an Agile Business Analysis Plan (Step 4)

When it comes to step 4 – creating your business analysis plan – this is where it’s important for the agile business analyst to integrate the business analysis process into your organization’s version of agile.

Here are some specific questions you’ll want to answer as you work through your planning:

• How long are sprints scheduled for?
• What happens inside a sprint? Is there time for elicitation and requirements work or is the sprint all about developing and testing?
• What is the desired outcome of a sprint? Production-ready code is the typical standard but ready-to-test code is also a common deliverable in partially agile teams.
• How does the project team decide what to work on inside a sprint?
• What state does a product backlog need to be in before a sprint?
• What state do the user stories need to be in before a sprint?
• Who is responsible for the product backlog and user stories? While these are natural responsibilities for an agile business analyst to take on, your project team may have a different way of doing things.
• What requirements work will happen inside the sprint?

Essentially, you want to figure out exactly how to fit your detailed functional requirements work into the agile process of your software development team.

Agile Business Strategy #3 – Plan for Multiple Iterations of the Detailed Requirements and Team Support (Steps 5-7)

Fundamentally, agile is an iterative development process. On the best agile teams I’ve been a part of, we developed a pattern of requirements, design, development, and testing that flows continuously so that everyone is always working on something meaningful. And this means the agile business analyst might be working on requirements that are developed and tested next week, or even tomorrow.

In the BA Essentials Master Class, we discuss specific ways to develop the detailed requirements iteratively in step 5. And it is important here to be sure you are eliciting, analyzing, and finalizing the requirements in an iterative, continuous fashion, so your product team has a steady stream of work for each sprint.

What’s more, while you are finishing requirements for the next sprint, you are also supporting the technology team during the current sprint (step 6). And you might also be supporting the business in implementing the changes from the previous sprint (step 7).

So steps 5-7 all happen, but they happen at the sprint level instead of at the project level, which means that in reality, you are working on all 3 steps at once.

In my experience, this is the biggest shift for us to get used to as agile business analysts, because this pattern of work requires us to manage our time extremely well and make sure we are working on only the most important tasks with each step. There is no time here for endlessly tweaking models or finessing the phrasing of requirements. Instead, we should be collaborating, reviewing, and getting all of our work “good enough” to take the next step.

Agile Business Analyst Strategy #4 – Regularly Assess Value in Step 8

Step 8 in the business analysis process involves assessing the value created by the solution. And here is where we as business analysts can start to fall in love with agile methodologies. In a more traditional, waterfall environment we might wait months or years to see our requirements implemented and the value intended by those requirements realized.

In an agile environment where production-ready code is delivered regularly, we might see slices of value realized within weeks. And that means we can also be assessing the value of those changes earlier, and communicating about the value already delivered by the project team before the team is even done with the project.

This kind of celebration and communication can create a lot of positive momentum inside our project teams and across our organizations. What’s more, as we see the initial changes deployed, we’ll often learn even more about what the next set of valuable functionality is, generating new ideas for new projects and backlog items, which will require regularly grooming the product backlog. Instead of staying stuck on what was originally in scope, it is important to leverage this learning and make adjustments.

An Agile Business Analyst is Still a Business Analyst

Although we might apply the business analysis process differently in agile, it’s just as important as ever to be a tried-and-true business analyst in an agile environment. In fact, if we try to skip over steps just because we are doing agile, we are likely to face more challenges inside our projects.

If you are a business analyst on an agile team, consider how you demonstrate leadership within your own domain of business analysis by applying these crucial strategies to increase your effectiveness.

Learn More About the Business Analysis Process

To learn more about the 8 steps business analysis process, sign up to receive this recorded webinar training – 8 Steps to Being an Effective Business Analyst. (It’s complimentary.)

You’ll learn about the 8-step business analysis process that you can apply whether you are in an agile environment or a traditional one, whether you are purchasing off-the-shelf software or building custom code, whether you are responsible for a multi-million dollar project or a one-week project.

Click here to register for the complimentary training

So, you’ve heard the news – your organization is going agile. Or you are looking for jobs, and every single one requires agile experience.

What does this mean for you, your career, and business analysis? How do you leverage your skills and experience in more traditional, waterfall environments to succeed as an agile business analyst?

That’s what we cover in today’s video.

For those who like to read instead of watch, here’s the full text of the video:

Agile is a huge opportunity for you as a business analyst.

I’m Laura Brandenburg. I’m the creator of Bridging the Gap. Today, I’m going to share exactly how you can move forward as an agile business analyst with a waterfall background.

First of all, agile teams definitely need business analysts. We give the requirements and the insight that help that agile team be successful. This is a huge opportunity for you as a business analyst.

Waterfall to Agile Tip #1 – Ground Yourself in Core Business Analysis Practices

The first thing to do, it’s important to just ground yourself in core business analysis practices and why they are important. This doesn’t mean you get to stick to your old way of doing things and kick and scream about how essential you might feel it is to create a BRD, a business requirements document, or an FRD, a functional requirements document, or whatever type of document you are used to creating as a business analyst.

This means you have the opportunity to look at why you create that document.

• What value does it provide?
• What do you find most helpful about it?
• Where would the team fail if you took it away?

I believe that business analysts create clarity and eliminate ambiguity. Your existing documentation is likely one tool for analyzing the requirements and doing so with clarity. There are many tools that you can use to do the same thing. So, understand your value. Your why. What you do and why it’s important. That’s your first step because you want to go into the agile team with that inner confidence and that inner self of value and personal power.

Waterfall to Agile Tip #2 – Let Go Of Your Existing Templates

Second, it’s going to be the hard one, let go of your templates. All of them. Poof. Just let them go. They’re gone.

You’re on a new project.

• What are you doing now?
• What questions are you asking?
• What decisions are you driving?

Take a moment to visualize if you let go of everything you do today, what would you do, what would you truly need to document and why? This can be a thought experiment. You don’t have to throw away all those templates and all that work. But can you trim it down significantly?

In our Business Analyst Template Toolkit, I provide my very streamlined shorter templates. They’re great alternatives to traditional BRD or FRD you might have been used to creating in a waterfall environment.

Waterfall to Agile Tip #3 – Collaborate with Your Agile Team

Talk to your agile team. What would help them the most? I’ve been on several agile teams and they all wanted different things from me on different levels of detail.

• What information are they expecting to have in place, and when do they need it?
• What deliverables will help them the most?
• Do they want to see wireframes, or data models, or use cases, or user stories?

They might not know. And if so, you can provide some examples and ask for feedback. They might have a very specific set of expectations.

When shifting to agile, it can feel like a lot of our traditional tools just get thrown out the window. I can remember my first agile project. I knew I had to trade my beloved use cases for user stories. I didn’t know what that meant. And so, it turned out that I still needed all of my use case thinking skills, and the user stories nearly became another way to package and communicate those functional requirements.

My core business analysis skills – that gaining clarity, that discovering needs and requirements for business stakeholders, clearly documenting, and analyzing, all of that was absolutely, positively essential to my agile team. Agile didn’t replace them and, actually, augmented the need for them. Even though our skills are important, we do need to shift some aspects of our work, so we can deliver the most possible value and earn the respect of our agile teams.

In the three steps I walked you through – thinking of your “why,” owning your value, discovering why it is you do what you do, at least going through the thought experiment of just throwing your templates away and coming up with what is essential to your success as a business analyst – and then deeply and intently, and consciously collaborating with your agile team.

Learning enough about agile practices, like user stories and product backlogs, and then going to your team with some ideas and getting their feedback along the way to make sure you’re creating requirements and documentation that help them deliver working software more quickly.

You do these three things, and your transition from waterfall to agile might not be easy; there might still be a few kicks and screams, but it’s going to happen with more ease and grace, and you’re going to come out on the end, probably, appreciating some of the positive changes that you can experience, and your teams can experience, and your organization can experience when they transition to agile. I know I did.

It was a lot of fun getting to work on an agile team and getting to see my requirements become more closely modeled in reality and becoming a closer partner with the tech team than I had in more traditional environments. It’s a great way to accelerate my career and see more positive change happen more quickly for organizations.

I hope you had a lot of fun with it. I hope that it helps you grow your career. I’d love to hear what’s coming up for you as you go from waterfall, or traditional approaches, to more agile business analysis practices.

Again, I’m Laura Brandenburg, from Bridging the Gap. We help business analysts start business analyst careers.

Thanks for watching.

It’s my honor to bring you this interview with Ellen Gottesdiener and Mary Gorman. They recently published a new book – Discover to Deliver – which makes a significant contribution to the business analysis profession. I was privileged to be an early reviewer and I highly recommend their book to anyone looking for a solid grounding in how to apply BA practices in an agile environment.

In this interview, we cover why Ellen and Mary embraced agile analysis, the business analyst role in an agile environment, and list specific practices you can use to evolve your business analysis skill set and stay relevant in an increasingly agile world. (And if you are interested in the book, there’s a discount for Bridging the Gap readers at the end, so be sure to check that out.)

About Ellen and Mary

Ellen Gottesdiener, Founder and Principal with EBG Consulting, is an internationally recognized facilitator, coach, trainer, and speaker. She is an expert in Agile product and project management practices, product envisioning and roadmapping, business analysis and requirements, retrospectives, and collaboration. In addition to co-authoring Discover to Deliver: Agile Product Planning and Analysis with Mary Gorman, Ellen is author of two acclaimed books: Requirements by Collaboration and The Software Requirements Memory Jogger.

Mary Gorman, Vice President of Quality & Delivery with EBG Consulting, is an expert business analyst, facilitator, coach, and trainer. She has deep expertise in business systems and product development. Mary writes on requirements topics for the Agile and business analysis community and is a Certified Business Analysis Professional. Mary was instrumental in developing the IIBA^® Business Analysis Body of Knowledge^® and the IIBA^® certification exam. Mary is co-author with Ellen Gottesdiener of the recently released book, Discover to Deliver: Agile Product Planning and Analysis.

Making the Transition to Agile Analysis

Laura: Over the last 10 years or so, you’ve transitioned from a focus on business analysis to Agile analysis. What was the key driver in this transition for you both as consultants, coaches, and trainers?

Ellen and Mary: We’ve been on this journey for about 12 years now, and we’re seeing more and more organizations adapting lean/agile practices. Just as important, we’ve seen how lean/agile practices amplify the benefits of business analysis.

Here’s why. Increasingly, our clients—like most organizations—need faster product delivery, super-efficient practices, and, above all, a relentless drive toward value. At the same time, they face a host of practical problems. First, products are complex and therefore expensive to build and maintain. Second, customers are getting more savvy and demanding. Next, requirements risks continue to be the most insidious challenge in any development effort. And then there is the fourth practical problem—people. Products are discovered and delivered by teams of human beings whose best work emerges from healthy collaboration. But that doesn’t happen spontaneously. People need to learn how to systematically plan and analyze the product at a high level while at the same time drilling down to the details.

A core element of these problems is the need to specify product requirements, the basis for development and delivery. While technologies get better and better, requirements remain a conundrum—they are necessary to know, but wickedly difficult to obtain and agree on. Requirements will always be, to paraphrase Fred Brooks, the most difficult part of any development effort.

The world recognizes the value of lean/agile development for many products: you have to plan for uncertainty, work on small batches of requirements, deliver them as soon as possible, test your assumptions about which requirements will deliver the most value, and all the while instill a sense of partnership among stakeholders. We’ve found the best products come from teams that act as a living learning lab—constantly delivering, learning, and improving. This continual improvement cycle is the hallmark of a successful lean/agile team.

Agile analysis synthesizes a toolkit of practices drawn from business analysis as well as requirements, project, and product management; strategic thinking; and collaboration.  We’ve been fortunate to work with a variety of clients either interested in or compelled to adapt how they go about business analysis and requirements practices.

When calibrated for the situation at hand (after all, context counts) agile analysis practices help product partners build the right product right, discovering and delivering high-value, high-quality products.

Also, before we go on, let’s take a minute and define what we mean by lean/agile. As defined in Discover to Deliver, lean/agile (or sometimes just agile) is “an umbrella term describing the family of practices for building software and systems using iterative and incremental development and delivery, with a focus on maximizing customer value while minimizing waste.”

The Business Analyst Role in Agile

Laura: You have been vocal for a number of years, in both the traditional and the agile communities, about distinguishing the agile BA role from agile business analysis work. Why? 

Ellen and Mary: Yes. We prefer to focus less on roles and turn the focus to goals. To that end, we published a widely referenced article, “It’s the Goal, Not the Role: The Value of Business Analysis in Scrum,” to jump-start this conversation.

Here’s why. As we observed agile teams, we saw many of them ignoring or avoiding requirements analysis, and they ended up delivering buggy software, fragile architectures, or products that had little value to users or buyers. In addition, we continued to hear a hue and cry from analysts who were confounded or worried about whether and how they fit into agile projects.

Before we talk about how business analysis skills fit, let’s clarify the work that needs to get done.

The entire product community—from the customer, business, and technology realms—shares responsibility for discovering the highest-value product to deliver at any given time. To continually make smart decisions, these people need to act as partners to explore product options, evaluate them to identify those that have high value, and define confirmation criteria to verify and validate the delivered product. This is the work of knowledge discovery—in other words, analysis. Furthermore, it’s not a one-shot deal. It’s ongoing. And it requires discipline.

This knowledge discovery work requires people who have interconnected skills such as strategic thinking, evaluating, and envisioning; elicitation, analysis modeling, and efficient specification; user experience and design thinking; user acceptance testing; and facilitation. Talented business analysts have all or most of these skills.

Laura: Given that distinction, and to use the language of “role” applied to agile teams, what business analysis skills and knowledge are applicable to which agile roles?

Ellen and Mary: Here are a few examples.

• A person (possibly a business analyst) who has skills in testing; defining lean, testable requirements; and turning examples into acceptance tests may serve as a tester.
• A person (possibly a business analyst) who has good analysis modeling skills, knowledge of user experience design and architecture, design skills, and a bent toward empathy for users may serve as a user experience designer.
• A person (possibly a business analyst) who has excellent facilitation, communication, coaching, and leadership skills may serve as a project manager, release manager, scrum master, coach, or software manager.
• A person (possibly a business analyst) who has rich domain expertise, especially in large organizations, may serve as a tactical product owner—assuming that the product champion gives the analyst decision-making authority.
• A person (possibly a business analyst) who is a domain expert, has strategic planning and thinking skills, and has a background in product management may serve as a product champion (also called a product owner or business owner).

How to Expand Your Agile Analysis Skill Set

Laura: I know many of our readers realize that Agile and Lean are significant industry trends, but are not yet employed in Agile software development environments. What concrete steps can they take to make their business analysis experience more relevant to an Agile environment so that they can remain competitive in the job marketplace?

Ellen and Mary: Indeed, we see agile less as hype and more as mainstream, commonsense practice. Agile has crossed the chasm of software practices. In other words, just as object oriented development went from hype to trend to common practice in software development, so too is agile becoming the standard product planning and analysis.

Business analysts need to take note: most organizations—especially the ones business analysts want to work for—are integrating, hybridizing, and synthesizing agile practices into the way they do business.

Here are specific recommendations for business analysts:

1. Learn the foundational principles and practices of lean, agile, and organizational change.

2. Become fluent in a variety of ways to elicit and specify product needs driven by value. This includes product visioning, goal and objective specification, risk assessment, and exploration and evaluation of options to fulfill product needs (product options) at any planning horizon.

3. Build mastery in analysis modeling. Learn how to use a variety of analysis models; how to select models based on the problem domain; how to calibrate models’ breadth, depth, and formality; and how to interweave them to yield clear and precise requirements quickly.

4. Learn how to think with, and specify with, a testing mind-set to verify and validate requirements concurrently. Find out how to devise acceptance tests from concrete examples and use them to both elicit and test requirements. Understand how to validate requirements by using measurable outcomes expected with each delivery. Learn how to help your technology, business, and customer partners by insisting on clear validation criteria.

5. Become a skilled facilitator, with the ability to design and lead collaborative work sessions for a variety of stakeholders, whether scopes are wide or narrow and time horizons are near term or long term.

We think these five steps not only will make you relevant and also will demonstrate the kind of business analysis leadership that makes you indispensable.

About Discover to Deliver

Laura: I couldn’t agree more. Tell us a bit about Discover to Deliver and how it will help new and aspiring business analysts apply Agile analysis techniques on their software development projects.

Ellen and Mary: By working with numerous agile teams—and non-Agile teams as well— we’ve learned, over many years, that great products are the result of stakeholders having a product focus, staying value-driven, and continually collaborating and conversing as partners. More and more, we’ve found ourselves homing in to help agile teams set context, be explicit about value, and learn from each other by having succinct, rich conversations about the product they’re working on.

We wanted to codify this know-how in Discover to Deliver in a way that would be useful and practical and would stand the test of time. After all, requirements are the basis for planning, architecture, development, testing, and, ultimately, product value. So we wanted to describe ways to do that well, honoring Lean/Agile principles.

Among other things, Discover to Deliver explains how to:

• Engage stakeholders as product partners.
• Identify value considerations in order to focus on high-value product needs.
• Clarify planning by recognizing multiple time horizons (we call them the Big-View, Pre-View, and Now-View).
• Plan and analyze product needs with increasing specificity according to planning horizon.
• Hold structured conversations to explore product options across the 7 Product Dimensions. The 7 Product Dimensions encapsulate what is classically referred to as functional and nonfunctional requirements. The structured conversation is a metaphor for the ongoing collaborative practice of exploring, evaluating, and confirming product needs
• Use the 7 Product Dimensions as an efficient way to holistically explore product options.

We took special care to make the book usable and practical for a variety of readers and learning styles. The book uses a straightforward visual language as well as text. In addition to a comprehensive glossary, the book offers a rich narrative case study that allows readers to “listen” as a team plans and analyzes requirements. And detailed case study examples are woven throughout the book. Readers can also refer to a suite of tools and techniques (with examples) that are mapped to the book’s key concepts and practices. A graphical navigation mechanism lets you see at a glance where you are in the book.

Laura: I know many of our readers already own and frequently reference Ellen’s Software Requirements Memory Jogger. How would you bridge their experience with that book to what they will gain from Discover to Deliver?

Ellen: I continue to be gratified when I learn of the value the Jogger book has provided to many people in our community—as well as many others in the software development community. Since I wrote the Jogger, Mary and I have adapted and extended traditional requirements practices as a result of our direct agile experience.

Discover to Deliver helps readers apply the foundational knowledge and skills described in the Jogger. The Jogger’s model essentials supplement Discover to Deliver, and vice versa. (We have crossed referenced the techniques in the two books, as well as mapped Discover to Deliver to the PMI-ACP® Handbook, PMBoK®Guide, IIBA BABOK® Guide and Agile Extension to the BABoK®; you’ll find these mappings on our book’s website, on the Resources page).  While it’s certainly helpful for Discover to Deliver readers to read the Jogger, it’s not necessary.

The same is true for my first book, Requirements by Collaboration. The essence of collaborative practices is as true today as when I first wrote the book. Many agile leaders and coaches are returning to Requirements by Collaboration to sharpen their skills in facilitating successful team collaboration.

>>Read More About Agile Analysis

Here are some additional Bridging the Gap articles about being an analyst in an agile environment:

• How to Create a Product Backlog
• How to Define Scope in an Epic
• How to Write User Stories

Adriana has already shared her views on how BAs help improve the quality of documentation on agile teams. I definitely concur! And today, I’d like to expand on that view by separating out the ideas of technical specs and system documents.

My Old Way of Doing Things

One beautiful thing about use cases is that they can play triple-duty. They are a decent tool as a technical specification. A developer can take a use case and begin to design and build code to support the functional requirements in the use case. They also often double as system documentation, which means that after all the code is written, the use cases are usable requirements documents in understanding the requirements of the system. Use cases are also a wonderful analysis tool in that they encourage you along your way of doing the hard thinking about how a system works.

As I became immersed in agile practices, I began to realize that placing these three different needs onto every document I produced created unnecessary headaches. I sometimes stalled as I took time to “figure it all out”. If your documentation is going to help the team deliver AND be useful long-term, you need to know a lot more about the product you are building before you write it.

Similarly, I fought requests to change or refactor documentation, which I now see as a sometimes necessary part of the business analysis process. An update to one use case often means a bunch of related updates to other use cases. When you are on a quest for perfect system documentation, you can feel a lot like a juggler during the delivery cycle.

The Goal of Technical Specs

Agile practices, especially the focus on ensuring documentation is relevant to building working software, helped me see that there is a lot of value in customizing how you present the requirements specifically for the development team. When working with an agile team, the user stories organized in a product backlog are the main communication points about requirements. I break up and rewrite user stories all the time to suit the needs of planning and prioritization.  I aim to compartamentalize the requirements into small chunks of valuable functionality that can be built by the team in 1-3 days. This means that as I learn about the system and what it takes to build a specific feature, I update the backlog of stories. This requirements approach allows me to cater specifically to developers and help them be more effective.

Because use cases are such a wonderful analysis tool (just one of the many reasons I love them), I’ll often do some early use cases before I start defining my user stories. It helps me keep the big picture in mind and can be a useful tool to review with stakeholders and developers to understand the requirements and the concept. But I typically don’t use them as part of my technical specifications in an agile project.

The Way of the System Documentation

I still believe you need system documentation because it provides lasting value. I actually think that a documented system is more valuable than an undocumented system. Don’t you? Tracing through a large collection of user stories that build on top of another is an inefficient way of finding the answer to “how does the system work?”. And six months from now after you’ve left this project in the dust someone is going to ask you just that.

Thankfully, I’ve found that writing use cases after the system is built is a fairly low-bandwidth activity. Once you’ve built a product, retrospectively writing the use cases and capturing key decisions can typically be done in a small fraction of the time you spent on the product originally. For example, for a six month project I spent just a few days creating and updating system documentation.

The Pros and the Cons

I will admit, handling system documentation and technical specs separately does take more bandwidth from the business analyst on the project. In my experience, most of this bandwidth is consumed in reconfiguring the technical specs (or user stories) as you learn about the system and the delivery cycle.

But I think the reality is that if I wasn’t doing this in my more traditionally managed project, then someone else was. This probably fell to the tech lead or the project manager. And in the process, I’m sure some of the requirements were missed and we delivered less value than we could have. The business analyst can bring a lot of value to this reconfiguration because you can keep the whole system held together and ensure that each story continues to focus on value to whoever will use the system. You are not just splitting stories apart into pieces of code. You are splitting features apart into incrementally delivered requirements.

The other positive that comes from this additional effort is that I have a better tool to validate requirements with the technical team. In the past, this work typically ended with a use case review and a formal nod indicating “yes, we can do that.” And then I had to wait until the code was delivered to see if that was true. As part of being involved in planning and reconfiguring stories, I get a much better idea if the developers can make sense of the requirements and how they intend to build them. With improved requirements validation, I end up with better requirements in the end.

Looking to Improve Your Documentation?

Check out the Business Analyst Template Toolkit – my repository of go-to templates for streamlining communication amongst the business and software development teams.

Click here to learn more about the Business Analyst Template Toolkit

When working as an agile business analyst, I’ve learned to stay at least one step (but only a step or two) ahead of the development team to maximize our productivity. Let’s look at what the process of grooming the product backlog looks like and how it improves productivity.

Requirements Drive Planning in Agile

In agile, requirements (or user stories) drive planning. Requirements are managed in a product backlog of user stories. The user stories are ranked by priority and the highest priority items are detailed out.

There are differing opinions on what should be done prior to sprint planning vs. what should be done within sprint planning.   On the teams I’ve participated in, we focus sprint planning sessions on understanding a handful of user stories in detail and planning the tasks it will take to complete the stories.

This means that prior to planning I have prioritized the backlog, detailed out the user stories with conditions of acceptance, and collaborated with the development team on an estimate for each story. In many cases I found that estimates actually helped the business prioritize, so we estimated early and we estimate often.

There is definitely a different requirements cadence when grooming the backlog versus finalizing a set of use cases or functional specifications.

Meet Regularly with Software Developers about New Stories

I meet regularly with my software developers to talk about new stories and requirements that are being considered. In these discussions, we estimate the story if we have enough information. I also ask questions to understand the constraints. Oftentimes I’ll come away with information about how we can constrain a story to keep it small or what detailed requirements would require additional work. If there is not enough information to estimate the story, I come away with some open questions I can follow up on so we can estimate it the next time.

Sometimes these discussions reveal that something I thought was fairly small is actually a larger story and needs to be broken up, or what you might call an epic. All of this information helps me create a backlog that the developers can work with during planning.

Prioritize the Product Backlog

Most SCRUM and agile books will tell you to rank prioritize the entire product backlog. In my experience, this practice creates an extremely large amount of overhead. The value in rank prioritization is really with the product backlog items that might be addressed in the next few sprints. As such, I tend to break product backlog items up into releases or group them together in a general priority. Then, for the items that we have the capacity to address in the next few sprints I help the business rank prioritize.

Detail out the Highest Priority Backlog Items

As we head into sprint planning, I ensure that the highest priority product backlog items have detailed requirements behind them. These detailed requirements are captured in user stories. Along with the requirements for the story, I draft conditions of acceptance or the tests that need to pass in order for the story to be considered “done”. During sprint planning, we review the requirements in detail and often adjust them for clarity or to answer questions that come up. During the sprint, if the developer discovers a new condition or rule, we’ll often continue to adjust the user story so that the entire team has a shared concept of “done.”

To keep up with the sustained momentum of an agile development environment, grooming the product backlog for the immediate future is often the most important task a business analyst can do to help make the development team successful.

>> Learn More About Agile Requirements

Check out Use Cases and Wireframes – our virtual, instructor supported, professional credit course, where you’ll learn how to iteratively analyze and model functional requirements, and break apart use cases into user stories.

Click here to learn more about Use Cases and Wireframes

There are a host of activities that happen between a semi-defined need (i.e. an epic) and a list of defined requirements to be built (i.e. the user stories). The goal in creating an epic to scope out a feature or a project to get just enough clarity around the what and the why and dig into just enough of the how to create a common understanding of what will be achieved with a given set of work. An epic is a great way to keep track of the big picture in agile environments.

With that context, here are the sections of the epic template I use:

• A one sentence description of the feature, written in the syntax of a user story “As a [user] I can [do something] to [achieve some benefit]. This is probably the “epic” on your product backlog.
• Benefits. A list of the specific benefits to be achieved via the implementation of the feature. The goal is to answer the question of, “why bother?”
• Scenarios. If your feature supports more than one business process scenario, this is a good section to include.  Capturing the scenarios keeps the requirements process aligned with how people will actually be using the new software.
• Features list. Identify the features that are included in the “scope” of the epic. These can be written in the user story syntax as well and might logically become the product backlog items or the be broken up into multiple user stories.
• Existing functionality to integrate. Often you’ll be building a new feature on top of some existing functionality.  Overlooking the current capabilities the software needs to continue to fulfill is a common requirements oversight I want to avoid.
• Assumptions. A list of things you’ve assumed to be true that were validated (or invalidated in some cases) by the business stakeholders.
• Nice to have features.  More of the above, but these will result in lower priority or non-existent product backlog items.
• Out of scope. Especially if you come from a traditional background, it’s difficult to resist including this beloved section for what you’re not doing. And it can help keep your team on track in terms of delivering what absolutely is needed to create value. Without this section, otherwise out-of-scope items might creep into your product backlog and divert your team’s focus from delivering on the value proposition.

All of the above looks a lot like a typical requirements document. The difference is it defines the scope around one feature (not an entire project) and, although you might need to succumb t small margins and minimal formatting, you can fit the information onto a single page.   It’s more agile than traditional approaches in that we’re not scoping a huge project and then diving in.

>> Learn More About Agile Requirements

Check out Use Cases and Wireframes – our virtual, instructor supported, professional credit course, where you’ll learn how to iteratively analyze and model functional requirements, and break apart use cases into user stories.

Click here to learn more about Use Cases and Wireframes

It’s so easy to get into a rhythm of looking at one story after another, eliciting the requirements, defining the stories, and prepping them for implementation. After a few weeks of this, you can lose track of where you are at in the context of the project as a whole and it can become increasingly difficult to groom the product backlog.

On one particular release I worked on, there were 4 main pieces of functionality and about 60+ product backlog items that collectively delivered on that functionality.  Although most backlog items are relatively independent from the perspective of implementation they are inter-related in terms of how they fit together to achieve our defined business objective.

Moreover, much of this new application will be interfacing with a legacy system and database and exposing data from that system live to customers on the web for the first time.  The small minutia of what’s in a database field or what the status of a record is in a given state can have significant business implications and impact how decisions are made in the minutia of detailing out other stories.

The challenge I faced was how to expose these inter-relationships in a coherent way to support my own analysis and get meaningful sign-off on the product requirements.  In the past, I have relied on the rigor of more comprehensive use cases with accompanying wireframes to “hold it all together” so to speak.  Oftentimes 2 or 3 use cases might be inter-related to deliver a complex feature, but now I’m often faced with 10+ stories, which is a mite beyond that infamous “rule of seven” that the brain can hold at any given time.

What I ended up doing was creating a feature map, with each user story laid out in a hierarchy and used color-coding to show which stories were implemented and which were not. This helped us see that we’d been cherry-picking important stories across different big features, but hadn’t really finished a single big feature on the project.

We re-prioritized our stories, looking at what stories were most important by feature and what minimum number of stories could be used to consider a feature complete. This allowed us to approach a collection of related user stories together and made the requirements process go a lot more smoothly. I felt a lot more like I was writing my beloved use cases.

And it also helped me keep my sanity.

>> Learn More About Agile Requirements

Check out Use Cases and Wireframes – our virtual, instructor supported, professional credit course, where you’ll learn how to iteratively analyze and model functional requirements, and break apart use cases into user stories.

Click here to learn more about Use Cases and Wireframes

A product backlog contains a complete list of all requirements under consideration (written using a user story syntax – more on that below), rank ordered, and matrixed with other key characteristics that facilitate planning and prioritization.

Let’s look at how the product backlog emerged for one particular project and how decisions were made about what to include in the product backlog.

Switching from Traditional to Agile – And Getting Started on the Product Backlog

This project was initiated with a traditional approach. The business analyst created a fairly traditional scope statement and features list. The features list was fundamentally business-driven.  When I started work on the project we had not yet defined how we’d manage requirements communication with the out-sourced development team.

At the project kick-off with the development team, we reviewed a fairly final draft of the scope statement and started discussions around detailed requirements communication.  The development team is part of an agile shop, so regardless of who did it, a product backlog and user stories would be created. The team agreed that it made sense for the business analyst to own creating and maintaining the product backlog and user stories.

Blending Requirements and Design in the Product Backlog

Identifying a user story blends elements of requirements and design.  As I worked through my list, driven by my understanding of what the business wanted, I kept running up against the question of, “How will it make sense to build this in a delivery cycle?”

To balance these two perspectives, I drafted the product backlog, then we tore it apart as a team into deliverable nuggets of functionality. For us, the question the product backlog answered was, “Given what we know about scope, what is the best way to deliver in an agile environment?”  So, we were blending agile with more traditional methodologies a bit to the benefit of the business team (that cares about scope) and the technology team (that has optimized their development process to deliver in sprints).

Using the User Story Syntax in the Product Backlog

The second challenge I encountered really centered around the syntax of a user story. In the past, I’ve been an “ability to” analyst…never again.  This time I used the following syntax to write requirements in my original scope statement.

“[Somebody] does [something] with [some information]”.

This provides a much more powerful way to capture features and also ensures you are capturing all aspects of the feature. And the standard user story format?

“As a [user], I can [do something] so that [perceived benefit].”

These were surprisingly similar.  I really played around with the benefits statement and found that sometimes it added real value to the story and other times real confusion.  I decided to consider it optional for this project.

But the standard user story format was missing the “some information” component that had really helped flesh out many of my requirements.  Therefore, most of the product backlog ended up in the following blended format (items in parens are optional):

“As a [user] (with some information), I can [do something] (with some information) (for some perceived benefit).”

Evolving the Product Backlog

Over the course of the project, the product backlog continued to evolve and was “groomed.” As we drilled into the requirements behind some of the earlier user stories, we discovered they were bigger than anticipated. We broke apart user stories into two or more product backlog items. On occasion, we combined stories.

As new stories were added, we assigned them story points (a kind of estimate) and a general priority. We rank ordered the next 20 or so user stories. As stories were targeted for a specific sprint, we added that information.

The backlog became a tool to scope and re-scope the project and it proved exceedingly flexible. Since we were using Team Foundation Server (TFS) to manage our user stories, I could download the complete product backlog and with some simple formatting in Excel share it with the business team. Then I could input my changes and update the user stories. Eventually, we even got the syncing functionality to work so I could make updates in Excel that were reflected back in TFS.

Managing a product backlog is a key way for the business analyst to add value to an agile project. It’s a wonderful tool for keeping business needs in sync with development deliverables and for streamlining how the requirements get managed throughout the development process.

>> Learn More About Agile Requirements

Check out Use Cases and Wireframes – our virtual, instructor supported, professional credit course, where you’ll learn how to iteratively analyze and model functional requirements, and break apart use cases into user stories.

Click here to learn more about Use Cases and Wireframes