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:
- What is my role on the Agile development team?
- What is the most effective way for me to work with Product Owners?
- How do I make a smooth transition from writing detailed requirements specifications to crafting succinct and powerful user stories?
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:
- Incremental planning • Evolving requirements
- Delivering high business value outputs
- Building in quality upfront • Mitigating risks
- Encouraging high communication, and
- Empowering teams
each method offers a unique approach to achieving these outcomes.
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:
- What each specific user role is trying to achieve (“As a <>….”)
- How each role will use the solution to accomplish that objective (“….I want <>….”)
- What is the business value of the requested capability (“….so that I can <>”)
- How to measure whether or not that objective has been meet (the user story acceptance criteria)
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:
- Reduction of cost
- Reduction of time
- Reduction of risk
- Customer/Stakeholder satisfaction
- Elimination of waste
- Reduction of complexity
- Improvement to quality
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.
