This is the ninth, and final, post in a series 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.
The final step, assess value created by the solution, is critical to the effectiveness of an iterative, outcome focused approach and ultimately to the effectiveness of your organization.This step is relevant for all efforts, regardless of your approach. And unfortunately, it’s a step that is not practiced not nearly as often as it should be.
This step is tied closely with Step 2 – Discover the primary business objectives. That step identifies the metric you’ll want to use measure success. Step 8 encourages the use of that metric to determine if your work is moving in the right direction.
Assessing value is not a one time thing. You want to measure the impact of your most recent change to determine if you’ve solved the problem and determine your next steps. If you’ve reached your target, that’s a sign that you can stop work on this initiative and try to solve a different problem. If the metric is moving in the wrong direction, your team can determine whether you should back out the changes you just made because you may have made the situation worse. If you’re making some progress, but still aren’t happy, you can continue to work on the current problem and make further changes.
It comes down to using an agreed upon indicator relevant to your organization to determine success rather than merely gauging success based on deploying a specific set of outputs.
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.
Key Responsibilities
Evaluating the actual progress made against the business objectives for the project to show the extent to which the original objectives have been fulfilled.
One of the most meaningful ways you can help your team focus on outcome over output is to check the metric you’re targeting every time you deliver a change to your users. You want to see if the change you made is moving you closer to your target.
Depending on your metric you may need to allow a certain amount of time for the changes to your product and process to take effect. For example, if the metric you’re looking at is a monthly measure, you’ll need to let at least a month transpire before checking the metric and making a determination of the effect of the changes you made.
As a result it may be helpful to select metrics that have a shorter time frame so that you can shorten the feedback cycle. Instead of a metric that is per month, look for metrics that you can explore on a per week basis.
Communicating the results to the project sponsor, and if appropriate, to the project team and all members of the organization.
I’d change the text of this responsibility to remove “and if appropriate”. Your team needs to be up to speed on the impact your changes have on your target metric. You want them to make the appropriate day to day decisions to accomplish the desired outcome.
You also need to create a mechanism to keep people informed of your objective and your current progress toward that objective.
Conveying the status of your business objective is not a one time communication it’s an ongoing communication that you update after you introduce changes to your product and/or the corresponding processes.
Suggesting follow-up projects and initiatives to fully realize the intended business objectives of the project or to solve new problems that are discovered while evaluating the impact of this project.
When your team follows an iterative, incremental, and outcome focused approach you examine your business objective after every change, so you’re not suggesting follow-up projects and initiatives, you’re suggesting whether to continue to try and solve the current problem or move on to something else.
If your team follows this approach appropriately, you get away from the all-to common situation where your stakeholders expect you to cram everything they asked for in the first delivery because they’re not certain they are going to get any follow up attention.
Deliver a small increment that you think might solve the problem you face, deliver it early, check on the result. If you didn’t meet your target, you should still have some time and budget left to try something else.
This responsibility is about answering the question “are we done” in an outcome based way.