Business analysts often interpret the lack of mention of business analysis in most agile frameworks (Scrum, XP, SAFe) to mean that there is no place for analysis, and hence no place for business analysts in an agile setting.
Every word in that sentence was wrong.
In general, the frameworks (except, perhaps for SAFe) are not intended to be all encompassing. They are intended to be a starting point from which teams can build their own methodologies.
One thing that your team will inevitably add to your methodology is some way to make sure you all understand what you are supposed to build.
That’s where analysis comes in. Elicitation, process analysis, data analysis, and other analysis techniques help your team build a shared understanding of the desired outcome and help you to determine the best solution.
These analysis techniques are not your end result. They are merely tools to help you add value to your team.
To do that:
You do small bits of analysis throughout the entire effort to keep a focus on the desired outcome and build and maintain a shared understanding.
You pass on what you have learned to the rest of the team – both the output of the analysis techniques and the techniques themselves.
You make sure that key decisions get made. When those decisions are your responsibility make timely, informed decisions. When others are responsible for those decisions make sure they have the information they need to make timely informed decisions.
The resources listed below provide some ideas on how you can add value with analysis.
Resources
Use Analysis to Refine Features
You can get a lot of value out of having big items on your backlog (ie features or epics) because you can get a broad view of the overall output you might need to deliver without having to dive into detail on any one particular item too soon.
At some point, though you do need to dive into detail on something in order to start delivery. Feature refinement uses analysis techniques and provides a way to do that in a way that allows you consider options and focus on the essential aspects of the feature and discard the aspects that aren’t completely necessary.
Use Analysis to Describe User Stories
User stories help us to organize our work and our conversations. You can further describe those user stories with familiar analysis techniques such as models (mockups and process flows), acceptance criteria, and examples. Those techniques help us during the conversation to make sure we’re all on the same page and help us afterward to remember what we talked about so we can go build it.
Start your analysis with the outcome
Just because you could start work on a new product by brainstorming a bunch of user stories doesn’t mean you should. Chris Matts created the idea of Feature Injection, which in its simplest form suggests that get clear on the outcome you seek, and then gradually identify the features you need to deliver that outcome as you gain a better understanding of the situation.
Chris has since provided further explanation of how to do analysis starting with outcome, and following his genius for naming things, called it the Costwold Way. (Writing that makes me think of the weirding way with which it has absolutely no relation, apart from a similar name)
10 Tips for Analysis With an Agile Mindset
When thinking about analysis, people often think about a set of techniques, such as elicitation and modeling. While those techniques are important, the thought process you use when performing analysis is critical for determining the right thing to deliver. To give you an idea of what a good thought process looks like, here are my 10 tips for analysis with an agile mindset.
Analysis with an Agile Mindset
This lightly edited excerpt from Beyond Requirements:Analysis with an Agile Mindset describes a typical approach to analysis in software product development where teams exhibit an agile mindset. It places into context most of the techniques described in the technique briefs on the site. This approach to analysis happens in four steps.