10 proven approaches for transitioning from a traditional business analyst role to an Agile business analyst role (Part 1 of 2)
Making the switch from traditional software development approaches to Agile methods can be a challenge for any IT professional but it is especially challenging for business analysts. Although there are thousands of resources available to guide Agile teams, relatively few of them are written specifically to answer the Agile business analysts' most common questions:
And, most important, how do I get started?
This two-part article will provide you with 10 steps as a starting path in your journey to becoming a successful Agile business analyst. Here are the first five steps:
Step 1: Research Agile Methods
This first step is inherently obvious but often overlooked. Take the time to become familiar with the broad range of Agile methods that are used for software development, software maintenance, project delivery, and integrated project governance. Although these Agile methods share the same basic objectives of:
each method offers a unique approach to achieving these outcomes. The following article provides a good starting point for learning the basics of Agile methods: http://www.devx.com/architect/article/32761
Step 2: Change Your Mindset
Now that you know the breadth of Agile methods, the next step is understanding how these approaches dramatically differ from the traditional waterfall approaches you have used. Start by suppressing the urge for you to document every possible requirement at the start of the project. With Agile methods, requirements gathering is an incremental activity that starts with a shared product vision and evolves as the project progresses. Instead of classifying and prioritizing hundreds of requirements upfront, you work with the Product Owner throughout the project to identify the highest business value outputs at each point, making sure that they never lose sight of the big picture view. Your goal is not to communicate with the team through a doorstop of written documentation. Your goal is to work hands on with the Product Owner to craft user stories that describe the highest value capabilities that will deliver this shared vision, to work side-by-side with the Agile development team to refine and clarify these stories, to actively participate in the review of the built features, and to continue to work with the Product Owner to establish the next set of high priority user stories for incremental delivery to achieve that vision.
Step 3: Support the Product Owner
One of the biggest challenges for an Agile project is the amount of responsibility that is given to the Product Owner with very little support. On most projects, the Product Owner is solely responsible for gathering, clarifying and prioritizing requirements on behalf of all of the business areas. It can be a very daunting and time-consuming task. As an Agile business analyst, you have the opportunity to work directly with the Product Owner to help them research, assess, prioritize and document their business requirements including all of the departments and users who are impacted by the solution. You can use your understanding of the business needs to create and maintain the big picture context. You can also serve as a liaison with the Agile development team throughout each iteration to minimize the workload for the Product Owner, especially where they have ongoing commitments in their primary business roles.
Step 4: Think in User Stories
Your most critical role in assisting the Product Owner is to help them translate their big picture vision into manageable user stories at a level of granularity that is actionable by the Agile development team. To do this most effectively, you need to keep the focus on:
Here are two excellent resources that can help you translate high level requirements into actionable user stories: Patterns for Splitting User Stories (http://agileforall.com/patterns-for-splitting-user-stories/) and 10 Useful Strategies for Breaking Down Large User Stories: (http://blog.agilistic.nl/10-useful-strategies-for-breaking-down-large-user-stories-and-a-cheatsheet/)
Step 5: Focus on Business Value
At the heart of Agile methods is the regular delivery of the highest business value features to maximize the ongoing return on investment for each project (and to minimize the impact of an early project exit). As an Agile business analyst, one of the most important roles that you can play is in helping Product Owners assign realistic business values to their user stories and prioritize them based on the highest value capabilities across the organization. Simple, right? Not always. Business value assignment may be achievable if the Product Owner can quantify the business value for each user story in terms of:
If these benefits are not easy to measure, however, you may need to work with the Product Owner to assign relative values to each user story. Either way, your objective is to avoid the tendency for Product Owners to prioritize user stories based on the most vocal user group, the features that would be most appealing to management, or the ones that are the easiest to develop. Your job is to keep the Project Owner continually focused on prioritization by business value return.
Part 2 of this article will provide you with five more tips for becoming a successful Agile Business Analyst.
How Agile is your Operating Model?
10 Steps to Becoming an Agile Business Analyst (Part 1)
10 Steps to Becoming an Agile Business Analyst (Part 2)
How to Be Agile in a Non Agile Organization (Part 1)
The Leadership Principle: Executive Impact on Agile
The Single Best Measurement of Agile Success
5 Questions to Ask Before Adopting Agile
Turn Your Waterfall Experience into Successful Agile Delivery
There are no products in your shopping cart.
| 0 Items |
Membership at BPMInstitute.org includes access to our other communities
From what I see of Agile, it
I come from a background of an Industrial Engineering degree, I/T development, Project Management, and then Business Process Management (BPM). BPM opened the door for me of ensuring that whatever we do in I/T, a business process is improved. Business processes can also be improved in many cases without I/T.
Measurement is a key, and setting goals for a business process and measuring how well a business process is meeting these goals is critical.
So ... back to User stories. To me, the important thing is to make sure the business goals are clear and measurable. Then you can figure out which processes affect those goals, and then start the journey to improve those processes. Traditionally, you would walk through the processes and determine what needs to change in which tasks to affect meeting the goals. Agile then provides a very nice method to incrementally improve the processes. The User stories then can be discovered in context of the business processes - making sure that the envisioned solutions are truly business focused, not I/T focused.
It's kind of like the difference to the way requirements used to be discovered and documented. We used to sit down with the user and ask "what are your requirements?". But how do you know you got the requirements right? By having the business process to provide context, you can:
- make sure the user stories are relevant to the business
- determine if one User stories creates a problem somewhere else in the business processes
- identify both manual and automated aspects of a user story
- measure the results by measuring how the business process results improve
There is never one silver bullet. Using various techniques together usually brings the best results. BPM implementations can benefit nicely from Agile, as you can make incremental improvements in a nicely controlled and monitored methodology.
So, in summary, I believe the Agile methodology is very good. The trick is the User Stories. If they are random, success will be random. If they are created scientifically with business process improvement in mind, the chances for success improve dramatically.