Most agile approaches don’t include the role of the business analyst (BA) or even discuss any analysis work. Analysis is the process of understanding needs, finding the root cause of problems, and brainstorming about the best solutions. This is a critical-thinking process that considers impacts and ramifications before acting. And this is the expertise of a business analyst.
What is the Role of a Business Analyst?
Some people think that analysts are not needed because formal requirements documents are not necessary in agile. After all, a significant part of business analysis does focus on requirements. But the most important work of an analyst is to analyze! Sometimes analysis will slow the quick development of a product—slow it down to consider the ramifications and impacts. In agile, an analyst can facilitate conversations to help the team think critically and consider impacts before building a feature or function. This facilitation doesn’t always leave a paper trail (requirements documents), but the fact that you can’t “see” the analysis does not make it any less important or unnecessary.
Analyzing the Business Value
Without analysis, a product owner’s request may be built into the product without considering whether the request is really a good idea.
Here’s a simple example:
When you include a business analyst in the conversation, it slows down the process:
Developer
Now a discussion ensues about what the product owner thinks are the advantages of cookies, and the developer explains the technical behaviors and results of using cookies. Maybe the product owner heard someone else talking about the value of cookies but really doesn’t understand the benefits or costs. What is the product owner trying to accomplish? The three members of the team then decide if cookies accomplish the goal or if there is a better way of solving the problem. Many people see this process as a barrier or block to development because it adds more time. But rather than being a block, analysis and critical thinking result in better-quality product features. They prevent mistakes from being built into the product, saving time and cost that would later be spent on rework.
I’m not criticizing agile developers. An experienced developer who is also analytical might ask these same questions, but an inexperienced or contract developer might not. It is critical we have a team member whose focus is to think about the requests and discuss the alternatives; it doesn’t matter whether that person’s title is BA or not.
Does this process take longer? YES, and that is a good thing. Analysis is the process of understanding needs, finding the root cause of problems, and brainstorming about the best solutions. Yes, analysis takes time, but it is time well spent.
- Satisfying Stakeholders with Agile Requirements - January 25, 2023
- Business Analysis: The Best Way to Start a Project - March 2, 2022
- Three Proven Ways Analysis Prevents Scope Creep - December 29, 2021
In some ways, agile teams can be quite conservative and reactionary: having misinterpreted one item in the agile manifesto to mean “no documentation”, this can lead to,the rejection of any role or process that typically involves documentation, such as a BA. And the concept of “eating the backlog with a fork, like spaghetti” can make teams more insular rather than more open. My most often used phrase as a PM these days seems to be “hasten slowly”
In your example, a product owner who said “I want cookies” without doing the analysis should be fired. The product owner and the analyst are the same person in your example.
First – the product owner should never be specifying design choices (e.g. cookies vs. user authentication vs. supercookies, etc).
Second – the product owner should only ever be helping the team understand the prioritization of solving particular problems (e.g. we need to be able to correlate current session behavior with prior session behavior, so that we can […])
You can then have an analyst who says “here are the seven ways we could achieve that end, 5 of them are consistent with corporate policy, 3 of those will work for >90% of our users based on the platforms we are supporting, and 2 of them are within the reach of our team’s ability to implement – with costs of X and Y and functional trade-off Z.”
The analysis should be done. It can be done by the product owner, by a developer, or by an analyst.
I think you can make a more compelling case if you don’t base it on a hypothetical product owner who needs to be fired for not actually doing their job.
Scott,
Thanks for your note. Firing a product owner who asks for something doesn’t seem like a realistic option. Business people (product owners) often hear about technology ideas/terms and, without completely understanding the technical details, ask for them in requirements. The reason business analysts are so valuable is that we are trained to ask the “why” question and look at the options as you describe.
We would like for all product owners to understand their role, but I’ve worked with thousands of business people and they often ask for things which are technically outside of their role. Our job is to help them figure out how technology can improve their business. Barb