This is the seventh 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.
No matter how diligent you are, no matter how many times you discuss things, no matter how many process models you sketch, acceptance criteria you define, examples you identify, your team is going to still have questions.
Just accept it.
When there are questions, that doesn’t necessarily mean you did a bad job describing the backlog item. You’re running into a truism about knowledge work in general and software development in particular – you learn throughout the entire process.
What all this means is that you will spend part of your time working with the team as they build the solution while you’re getting the next backlog items ready.
There are certainly advantages to spending time with your team as they build the solution. You can get an idea of what questions come up as they dig into a backlog item which may help you to revise your approach to getting the next items ready.
It’s not bad when your team has questions about a backlog item you’ve already described. It is bad if your team has the same question about one backlog item after the other. That’s a sign that you aren’t learning from experience.
How To Be An Agile Business Analyst
As a business analyst, you have probably wondered how agile impacts your work. You may look at the popular agile frameworks, notice that business analysts aren’t mentioned and wonder whether you fit.
The key is to not focus on the frameworks and prescriptions, but rather to apply your business analysis skills in an agile manner so that your team solves the right problems with the right solutions. How To Be An Agile Business Analyst shows you how.
Read How To Be An Agile Business Analyst to uncover ways to add value to your organization, make your team more effective and build a more rewarding career.
Reviewing the solution design to ensure it fulfills all of the requirements and looking for opportunities to meet additional business needs without increasing the technical scope of the project.
This type of review primarily occurs when you get your backlog items ready, so the applicable part of this responsibility is dealing with additional business needs that your team identifies while building the solution or that your stakeholders realize they hadn’t identified yet.
When new business needs come up, it’s tempting to point accusingly at whoever brings up the new need and shout “Scope Creep” at the top of your lungs.
Whether that’s an accurate assessment depends on how you define scope. If you define scope based solely on output (the backlog items you deliver) then it sure feels like additional scope. If instead you define scope based on the outcome, the label scope creep is unfair. It’s merely a clarification of understanding.
Here’s how these new needs usually come up: Your team starts working on a backlog item and as they build the solution “what happens in this situation” question enters their head. You’d like to get most of these identified during example mapping, but some will inevitably sneak through.
Your role in the discussion when it occurs is to talk through the situation with your team. Make sure the team has a shared understanding about what the need actually is. I’ve come across many situations where what some people thought was a new business need was really just a misunderstanding.
Try to understand how frequently the new situation occurs (or whether it’s actually a real thing). Identify existing aspects of the solution that may address the need and then figure out a way to address the need with as little work as possible.
Updating and/or repackaging requirements documentation to make it useful for the technology design and implementation process.
Remember that requirements are a means to an end. The purpose of analysis activities are building a shared understanding, not creating requirements.
With that in mind, if you find that the way you describe backlog items could use some improvement, you’ll most likely adjust your approach describing future backlog items rather than dramatically changing how you’ve described the backlog items the team is currently working on. Sure, you may update the information you recorded about the current backlog item to reflect anything the team discovered in order to maintain a shared understanding, but you probably won’t make substantial changes to an item that will be delivered within the next week.
Resist the urge to update backlog items merely to reflect how they ended up getting implemented for future reference. That’s the purpose of system documentation, which will generally be a different artifact created specifically to provide information for your product as built. Backlog items are intended to be temporary artifacts that describe the change needed to go from current state to future state.
Engaging with quality assurance professionals to ensure they understand the business context for the technical requirements. This responsibility may include reviewing test plans and/or test cases to ensure they represent a clear understanding of the functional requirements.
This responsibility should probably be included in the previous step. You want to include people with a quality assurance outlook in your backlog refinement discussions so that they can suggest “what if” scenarios and get an understanding of the business context through involvement in those discussions.
If QA people don’t get up to speed on backlog items until those items are being built, you run the risk of not having a shared understanding. You also introduce the likelihood for delays delivering those backlog items because your QA people may not be ready to validate the solution when the team finishes developing it. Finally, you’ll end up with different views of acceptance criteria because the people who implemented the backlog item doesn’t have the same understanding of success as the people who are validating it.
Making yourself available to answer questions and help resolve any issues that surface during the technical design, technical implementation, or testing phases of the project.
The spirit of this responsibility is right on, although it should probably be reworded as “Make yourself available to answer questions and help resolve any issues that surface as backlog items are developed and tested.”
You don’t have technical design, technical implementation, or testing phases. Those activities happen on an ongoing basis as does a deeper understanding of backlog items (see the previous step).
Managing requirements changes to ensure that everyone is working from up-to-date documentation and that appropriate stakeholders are involved in all decisions about change.
Not only do you build shared understanding, but you also need to maintain it throughout the initiative. As your team identifies new scenarios for a specific backlog item or identifies new needs, work with the team and stakeholders to make sure everyone is aware of the new information and discuss an appropriate way to address that new information.
When appropriate, leading user acceptance testing efforts completed by the business community to ensure that the software implementation meets the needs of business end users.
Whenever possible, give your users an opportunity to have meaningful exposure to your product as soon as possible so that they can use it and provide meaningful feedback.
You may need to change your view of acceptance testing from “test to make sure we delivered the solution correctly” to “determine whether this solution solves our problem.” This change in perspective means that you no longer ask your users to duplicate testing your team is most likely (or should be doing) and instead focus on whether the solution solves their problem.
Your role in this is to help your users understand the purpose of doing that acceptance testing, and help them structure their testing efforts so that they can achieve that purpose.
User acceptance testing is also a great way to help with the next step by getting your users familiar with the solution.
Up Next: Help the business implement the solution
The next step in the business analysis process is to help your stakeholders and users implement the solution. Hopefully you’ll make incremental deliveries throughout the initiative, so this is also activity you’ll repeat multiple times rather than a step that occurs just once in a project.
The next post takes a look at what this activity looks like for an agile business analyst.