This is the eighth 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.
It’s always been important for your users to understand and properly use the new features you deliver.
You’ll have much more interest in helping them use new features properly when you when you define success based on achieving a specific outcome, instead of merely delivering the features your team said they would deliver.
You may think that this step is all about training users about new features, and that’s certainly part of this step. It’s also important to think about what other changes (such as business processes, work instructions, and policies) need to occur to get to your desired outcome.
You’ll also want to consider what transition activities you have as a result of the changes your team made, such as updating data to work appropriately with the new functionality your team built.
It’s best to consider the activities in this step early on – such as when you identify potential solutions. If you consider this step early, you may discover that it’s possible to achieve your desired outcome with process and policy changes and without any software changes.
Understanding what you need to do to implement the solution can also help to define what transition activities are required so that you plan for the time necessary to do those activities, and perhaps incorporate some of those transition needs in the team’s work.
Training users is also important. That training should cover not only the changes to your product itself, but also the business processes impacted by your product or the changes to it.
You can forego training, but only if you build your product to be so intuitive that training on the software itself is not necessary. I realize that is easier said than done (I can attest to that from personal experience).
If the nature of your product is such that you still need to provide some training to users, you don’t have to wait until you’re actually delivering the product to show them how to use it. Make use of reviews to not only show customers, users, and stakeholders what your team is working on and get feedback, but also show them how the product works, and let them try it out.
As with the define detailed requirements and supporting the technical implementation steps, this activity is not a one time occurrence. It happens every time you deliver a new increment of the solution to your users. The good news is since you (hopefully) deliver small aspects of the solution, you can focus on small set of changes.
Ironically, the frequency of your deliveries may be driven by whether your stakeholders are able, or willing, to make small frequent changes to their processes.
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
Analyzing and developing interim and future state business process documentation that articulates exactly what changes need to be made to the business process.
The extent to which you carry out this responsibility is based on the extent of process documentation that you have. As with all documentation it’s best to create documentation with a purpose.
Complete enough documentation to properly convey the necessary information, but no more complex or extensive than necessary. The documentation doesn’t have to be extravagant. As with the features, any documentation you provide or update related to business process changes should focus on building and maintaining shared understanding and should not be considered the sole means of communicating business process changes.
This is often an activity that’s best performed collaboratively with your stakeholders and users. If you work together to discuss and revise impacted business processes, your stakeholders and users are going to have a better understanding of the changes, and they will bring their knowledge and understanding to bear to make sure you consider all of the necessary changes.
Training end users to ensure they understand all process and procedural changes or collaborating with training staff so they can create appropriate training materials and deliver the training.
Sometimes a general overview of the changes that you’re making is sufficient. In other cases you may need to put together reference material for users, and in other situations you need training sessions to get your users up to speed.
The more intuitive you make your product, the more likely you only have to provide specifics of upcoming changes and possibly user documentation.
Once you’ve provided user guides, your ongoing changes should not require completely new guides as much as updates to the existing guides.
A word of warning – it can be very easy to forget to change your existing user guide, so be sure to incorporate some mechanism to remember to update that documentation when you make changes.
An example of a user guide is the Submission System Guide I put together for Agile Alliance’s Submission System.
Collaborating with business users to update other organizational assets impacted by the business process and technology changes.
Most of the work you do with your stakeholders and users to rollout changes helps them revise impacted business processes and helps them get up to speed on changes to your product. There will always be other items you need to update. Those items may include:
- Work instructions for people who may not use your product but may be impacted by it.
- Communication to customers about how the changes you’ve made will impact them.
- Communications to stakeholders outside your organization that may be impacted by the changes you made. Depending on the impact, this communication should happen before you deliver the changes.
An organizational asset that you’ll need to update, and often is forgotten until deployment time, is any data that the process uses or product processes. When you start working on changes, think about the data involved and how it’s impacted:
- Do you need to perform some transformations to data when you implement your changes?
- Do you need to update other systems that use data from your product?
- Are there reports that need to be updated or created?
- Are there provisions you need to make to track metrics that you identified as measures of success?
A final thing to remember when you implement your solution is that no matter how effectively you communicate with your stakeholders, users, or customers you will still have questions. When those questions come up, don’t look on it as a failure in your communication. See those questions as an opportunity to identify how to improve communication for the next roll out. Chances are you’ll have plenty of opportunities.
Up Next: Assess value created by the solution
The final step in the business analysis process is to assess value created by the solution. This step is not practiced nearly as often as it should, and it becomes even more important when you follow an iterative, outcome focused approach. Instead of something that just happens once at the end of a project, this is something that should occur every time you deliver changes so that you can determine whether you should keep going, change your course, or stop the initiative.
The next post explores how agile business analysts can help their team to assess value.