This is the sixth in a series of posts that take a look at the agile business analyst in terms of Laura Brandenburg’s 8 step business analysis process which serves as the foundation for Bridging the Gap’s BA Essentials Master Class. Go to The characteristics of an agile business analyst for an introduction to this series.
You’ve determined the overall scope for your initiative and created a broad understanding of your solution. Now it’s time to deliver an increment of that solution – minimal enough that you can get fast feedback; but substantial enough that the solution is viable enough for that feedback to be meaningful.
In order to deliver part of a solution that’s minimal and viable, you need to make sure your team has a shared understanding of the problem and solution.
When you’re ready to start delivering increments of your solution, select an item (or collection of items) from your backlog and delve into more detail about that item. Backlog items are generally recorded in the form of user stories so I’ll refer to them as such for the rest of this post.
Don’t get sucked into all the chatter about how important it is to write user stories in the proper fashion. It is important to make sure a user story represents something that helps you ultimately achieve the outcome you seek. Beyond that, how you write it is not as important as you might think. That’s because user stories were never intended to be the sole means of describing the solution and they were certainly not intended to be the only means by which you build shared understanding. They are placeholders for the conversations you have to build that shared understanding. You also shouldn’t take that to mean that you don’t record any information about the solution at all.
We don’t rely on user stories themselves to describe what we’re building. They’re the outline. The description comes in the form of the models, acceptance criteria, and examples we create during our conversations and keep around as we build the product.
Start with a user story that you think your team will want to deliver soon – within the next sprint if you’re using Scrum for example. Determine if there are any key stakeholders that you need to talk to in order to understand the intent of the user story. Invite a couple members of your team that can look at the situation from the perspective of development (what could we build to solve the problem the user story represents) and testing (what happens when?). You may also want to include someone who has insight into good user experience. Have a conversation with that small group to get a better understanding of the user story. Those conversations are what many teams refer to as backlog refinement.
Talk through what the user story is trying to accomplish. As you talk, create one or more models to aid your conversation. The model you pick varies depending on the type of problem you’re trying to solve:
- If you’re providing support for a business process, a process model is probably the best route to go.
- If you’re solving a problem that involves collecting a lot of information, a user interface is going to be your best bet.
- If you’re solving a problem by presenting a lot of information, you’ll want to mockup a report.
You may choose to structure your conversation using example mapping to help you identify acceptance criteria and examples that you can use to further describe the user story and build that shared understanding with your team.
The model provides the rich information about the user story that pictures always provide. The acceptance criteria fill in the gaps that the picture can’t convey and provides further understanding about how you know when you’ve delivered the user story successfully. Examples help to clarify your expectations about how the solution behaves in certain circumstances.
You may craft some of this information before you chat with your stakeholders and team members so that they have something to react to rather than starting with a clean slate. You may have conversations with your stakeholders first, and then discuss what you found out with your team. Your approach depends on how your team chooses to operate.
Just remember that the more separate conversations you have, the longer it will take to get to a shared understanding. Consider the tradeoffs involved with your selected approach.
Remember that the goal is not to create requirements. The goal is to build a shared understanding about the problem you’re trying to solve and your desired solution. Requirements are a tool you can use to build that shared understanding.
The key responsibilities described below sound as though there are three distinct activities that occur when you build detailed understanding. If you’re facilitating the conversations described above correctly, you actually fulfill all three responsibilities at the same time.
Eliciting the information necessary to understand what the business community wants from a specific feature or process change.
As you talk with your stakeholders and team about the user story, you want to understand the intent of the backlog item and how it supports achieving the overall outcome.
As you discuss the user story, you may identify questions that you need to do follow up on. In order to keep those conversations productive, it’s helpful to note questions and agree to research outside the conversation and follow up with everyone rather than continue the conversation in a swirl about that particular question when you don’t have a chance of uncovering any new information.
If you use example mapping to structure those conversations, you have a built in way of identifying questions for further follow up – red index cards.
Analyzing the information you’ve discovered and using it to create a first draft of one or more business analysis deliverables containing the detailed requirements for the project.
Shared understanding is more important than any artifacts you put together to build (or remember) that shared understanding. That said, those artifacts are first drafts of what you could call business analysis deliverables. The models, acceptance criteria and examples you identify during the conversations to describe the user story can also help you remember what you talked about.
You may expand on those artifacts if the team feels like they need more information to accurately describe the desired solution. This most often happens when you identify relevant examples in conversations with your stakeholders, and then flesh out those examples with gherkin (given-when-then) afterward so that your team has specifics to refer to.
Reviewing and validating each deliverable with appropriate business and technology stakeholders and asking questions to fill in any gaps.
When you discuss the backlog item with your stakeholders and team, you simultaneously uncover the intent, discuss the specifics, and validate that everyone has the same understanding about the user story.
If your team choose to have you sketch some specifics out ahead of time and then discuss it with them, those discussions take on a bit more of a review and validation nature.
Either way the intent is not focused on whether the “requirements are correct” rather it’s to confirm that stakeholders and the team have the same understanding of the intent and specifics of the user story. That is a subtle, but important difference.
Up Next: Support the Technical Implementation
The next step in the business analysis process is to support the technical implementation. This is where you interact with your team to help them out with the backlog items that they are currently delivering. In practice, you’ll find that you switch between building a deeper understanding of the next backlog items to work on and support the technical implementation on a regular basis. It may be helpful to think of these activities that occur in parallel depending on the needs of the moment rather than steps that occur in sequence.
The next post describes how an agile business analyst works with their team as they develop part of the solution.