Many business analysts feel that their role is not necessarily urgent. We’ve heard that agile parties don’t want “necessities” and so we assume they don’t want business analysts!
Nothing could be further from the truth. Here’s exactly why agile parties need business analysts.
For those who like to read instead of watching, here is the full text of the video:
Many business analysts feel that their role is not necessarily urgent. We’ve heard that agile parties, they don’t want requirements. Then we assume they don’t want us as business analysts. Nothing could be further from the truth.
I’m Laura Brandenburg. I am the creator of Bridging the Gap. Today, we are going to discuss why business analysts are absolutely essential for agile parties.
Recently, a member of our community commented that in his initial meeting with the agile practitioners, he felt that something was off, something was missing. She wasn’t sure what it was. After going through our free training, he discovered that it was part of the business analysis of the process.
Where do those requirements for those users come from for those user stories? What was the software supposed to do? That information comes from us, business analysts.
One of my mantras is that in every successful project, you will find a business analyst. This is true even if they do not have the title of Business Analyst.
Quickly, as nice as it is, it’s not a business analysis process. It’s a way to develop and deliver valuable work software for businesses. Agile team, they need business analysts.
- We need business users to discover what they need and want and to determine which changes will be most valuable to the business, so that we can use efficiently developed software development practices to deliver it most efficiently.
- We need them to collaborate with business users and sponsors throughout the organization and to align what they want and need, and to ensure that those items in the product backlog and those details in the user stories present real value to the business.
- They need to take a holistic view of our product backlog and find out all those internal related requirements and interdependencies and make sure that the parts of the working software are going to pay off again from that edge. The business process is over.
- In that note, they need to discover and analyze what those business processes are and help business users implement the changes needed to make the new software fully profitable. This is expected to make their job easier.
- Last but not least, we need them to keep the backlog well organized. Tidy up and prioritize it, and add those estimates and filter through, remove things and add things so that the team can easily see what needs to be done in the next sprint and then the sprint.
Quick practice and business analysis actually provide tremendous value for companies when they are effectively leveraged together. Let’s stop questioning why we need agile business analysts, and let’s see how we can work together to achieve the highest possible standards for our organization. Things will be much easier when we all work together as a team.
I have some more resources for you on how to be a quick business analyst. This video must have a link or go to bridgethegap.com/agile-business-analyst. In the environment of bridging the gap and agile software development, I have determined exactly how I can apply the business analysis process we teach. Be sure to check that out.
I’m challenging you. What would you do to be a better partner for your agile team today? How can you help your organization become more efficient? How can you combine agile practice and business analysis to deliver faster value to your business community?
Leave me a comment below. I want to hear about your success.
Again, I’m Laura Brandenburg from Bridging the Gap. Thanks for listening.
Quick Business Analyst: 4 Key Strategies for Success
To follow-up from this video, let’s look at 4 important strategies for applying business analysis process in a fast-paced environment.
Quick Business Analyst Strategy # 1 – Resist the temptation to skip steps 1-3
Most agile exercises make specific assumptions about what information business stakeholders can provide and how quickly they can make decisions. These estimates are valid within 5-7 steps of the business analysis process. But steps 1-3 (orienting, discovering the primary business purpose, and defining the scope) are still important.
As a agile business analyst, these decisions help you take the stakeholders into the steps that you need to effectively and repetitively provide the requirements in Step 5.
- The current ability assessment done in Step 1 will help you and your team discover simple, quick wins that can add value quickly.
- The business objectives discovered in Step 2 will help your team prioritize product backlogs to put the most valued items first.
- The opportunity decisions made in Step 3 will help your team stay on track and make meaningful adjustments to expectations.
Often, these steps begin before the “smart” part of the project, and it is wise to make time for them as a savvy business analyst.
(Incidentally, we cover each of the 8 steps of the business analysis process in our BA Essential Master Class.)
Quick Business Strategy # 2 – Create a Quick Business Analysis Plan (Step 4)
When it comes to the 4 steps – creating your business analysis plan – it is important for business analysts to integrate the business analysis process into the agile version of your organization.
Here are some specific questions you’ll want to answer while working through your plan:
- How long is the sprint scheduled for?
- What happens inside a sprint? Is there time for Revelation and Requirements to work or is Sprint all about development and testing?
- What is the desired result of a sprint? Production-ready code is the general standard but also ready-to-test code is a general distribution to partially agile parties.
- How does the project team decide to work inside a sprint?
- What is the condition of a product backlog before sprint?
- What should user stories be like before Sprint?
- Who is responsible for product backlogs and user stories? While these may be the usual responsibilities for a agile business analyst, your project team may have a different way of working.
- What requirements will happen inside the work sprint?
Basically, you want to find out exactly how your software development team will fit your detailed functional requirements with the agile process.
Quick Business Strategy # 3 – Detailed requirements and plans for multiple iterations of team support (steps 5-7)
Basically, agile is a repetitive development process. Being part of the best agile teams I have, we have created a pattern of requirements, design, development and testing that is constantly flowing so that everyone always works on something meaningful. And that means agile business analysts are working on requirements that will be developed and tested next week or tomorrow.
In the BA Essential Master class, we discuss specific ways to develop detailed requirements repeatedly in step 5. And here it is important to make sure that you are figuring out, analyzing, and finalizing requirements in a repetitive, continuous fashion, so your product team has a steady flow of work for each sprint.
What’s more, while you’re finalizing the requirements for the next sprint, you’re supporting the tech team during the current sprint (Step 6). And you can support the business by implementing changes from the previous sprint (Step 7).
So steps 5-7 will all happen, but they will happen at the sprint level instead of the project level, which means in reality, you are working on 3 steps at once.
In my experience, this is the biggest change for us to become accustomed to as agile business analysts, because for this pattern of work we need to manage our time very well and make sure that we are working on only the most important tasks at each step. There’s no time to tweak the endless model here or fine-tune the phrase of necessity. Instead, we should cooperate, review and do all our work “well enough” to take the next step.
Quick Business Analyst Strategy # 4 – Evaluate step 8 regularly
Step 8 of the business analysis process involves evaluating the quality created by the solution. And this is where we as business analysts begin to fall in love with agile methods. In a more traditional, waterfall environment we can wait months or years for our requirements to be realized and for the value set by those requirements to be realized.
In a fast-paced environment where production-ready codes are regularly delivered, we can see the price slices available within a few weeks. And that means we can anticipate the value of those changes in advance, and communicate with the project about the values already delivered by the project team before the team completes.
This kind of celebration and communication can create a lot of positive momentum across our project team and our organization. What’s more, as we see the initial changes put in place, we will often learn more about what the next set of valuable functionality is, creating new ideas for new projects and backlog items, which will require regular product backlog sorting. It is important to take advantage of this learning and adjust to it, rather than clinging to what was originally the opportunity.
A quick business analyst is still a business analyst
While we can apply the process of business analytics differently, it is just as important to try and be a true business analyst in a fast-paced environment. In fact, if we try to avoid the steps due to speedy work, we may face more challenges in our projects.
If you are a business analyst of a agile team, consider how you demonstrate leadership within your own domain of business analysis by applying these important strategies to increase your effectiveness.
Learn more about the business analysis process
To learn more about the 8-step business analysis process, sign up to receive training on this recorded webinar – 8 Steps to Becoming a Practical Business Analyst. (This is commendable.)
You will learn about the 8-step business analysis process you can apply whether you live in a fast-paced environment or a traditional one, whether you’re buying off-the-shelf software or creating custom code, whether you’re responsible for multiple tasks – a million dollar project or a week Project.
Click here to register for free training
