We do lots of Agile development projects at Credera. Among other things, this means that features are managed as a backlog of work, and the team’s priorities are continually evaluated and adjusted to focus on the most important work. For a business analyst, requirements are constantly refined to match business goals and priorities—sometimes on the fly. As the team prepares to develop a block of functionality, the business analyst needs to remain one step ahead to ensure requirements are properly defined and that each team member has what is needed for a successful sprint. This blog post will cover five ways a business analyst can maximize their effectiveness for the team during active development.
1. Know the Difference Between “How” and “What”
The primary function of a business analyst is to create requirements, and while the tool or format used to create the requirements may differ, one thing should remain consistent—language. Remember that the business requirement should explain “what” is desired, and it should not describe to the development team “how” to do it.
This may be especially difficult for someone with a technical background or someone who is extremely familiar with the system. When creating requirements, focus on defining the “who,” “what,” and “why” to create user stories that accurately reflect the end-user’s expectations, but avoid defining development level tasks required to implement the functionality.
When there is uncertainty, refer to the user story’s high-level business objective and keep the end-user in mind. The list of tasks required to satisfy the done criteria, or the “how,” should be defined by the development team. This will require working with the development team to ensure everyone understands and agrees upon the expected business goal of the user story. Additionally, technical hot keys or loaded terms should be avoided to limit confusion. For example, there is a difference between saying “a user should be able to relate two items together” and “create a ‘key-value pair’ when two items are selected in succession.”
2. Know the Business Analyst’s Role in Meetings
It’s important to understand the expected contributions before a meeting. A business analyst’s role in a meeting may be capturing system pain points, documenting enhancement requests, conducting interviews to verify and discover underlying business needs, assisting with a technical solution exercise, leading a demo, or perhaps capturing decisions and action items to be shared with the team later.
Meeting preparation should be determined by both the expected contributions during the meeting and the desired outcome of the meeting. For example, if attempting to discover or refine requirements, questions and assumptions should be documented ahead of time so that specific clarifying questions can be asked to ensure requirements are based on valid assumptions.
For solution exercises, it’s important that the development team is able to focus on the solutions they envision as opposed to documenting the conversation. Development conversations can quickly get technical, so remember that it is OK to avoid getting into the weeds with them so long as key takeaways, including the decisions and why they were made, are documented. That way, when it comes time to code the solution and someone asks, “Why did we decide to do it this way?” there will be some documentation available. An example decision may be: “A move to AWS was decided upon because the servers based in Denver will be outsourced by the end of the year.”
A good rule of thumb is that it will be the responsibility of the business analyst to capture decisions, action items, assumptions, and follow-up requests in meetings. Be sure to always send a follow-up recap email after the meeting so any discrepancies can be handled quickly.
3. Requirements Are Your Forte
An agile approach to requirement creation emphasizes communication among team members over rigorous documentation. To accomplish this, requirement gathering is intentionally delayed until a feature is nearing active development, thereby reducing re-work if business priorities change.
The job of the business analyst is to describe requirements in a clear and concise way that can be understood by all stakeholders and project team members. Finished requirements are most commonly described through acceptance criteria associated with user stories and will be leveraged in many different ways. For example, the product owner or project director may use requirements to define scope or priority, the QA team may leverage them to create test scripts, and a developer may use them to create the actual product.
A diverse audience can take away differing interpretations of the requirements if they are not clear and complete. As requirements become increasingly refined, it is important to step back and look at them as if reading them for the first time. Ask the following questions:
If provided a stand-alone requirement, would there be enough context to understand what’s being asked?
Does it require assumptions that aren’t documented? Would mock-ups be needed to envision it?
Is there any missing information needed for context?
If a requirement seems unclear to the writer it will certainly be unclear to someone else.
4. Understand Your Relationship With Scope
While working with team members to refine requirements, “nice-to-have” statements (“it would be great if …”) and enhancement requests (“can we make it do this too?”) may be made while discussing in-scope functionality. To determine if the request should be included in the project, ask clarifying questions to verify if the request is protected by the defined scope. Remember that no one is closer to the scope of the project than the owner of the requirements. Additional requirement requests that are not in scope should be documented as enhancement requests for post-launch improvement, as opposed to being added to the current requirement set.
If additional requirements are brought in, be sure these are labeled as such and that the product owner has confirmed their priority in relation to the other in-scope requirements. Small requests here and there always have the potential to turn into larger efforts down the road; therefore, “additional” requests should be labeled so that the team can identify “where the time went” by pulling up requirements that were added after scope was defined. When possible, requirement swapping should be leveraged; if a new key requirement is introduced to the project, be sure to have a list of potential lower priority items to defer.
5. Be the Facilitator
It is the business analyst’s responsibility to track down the answers to questions that may come up in development, validate assumptions, ensure that mock-ups are ready before they are needed, schedule meetings, and send status reports. A business analyst should fill in the gaps of the project, and sense the needs of the project team before they arise.
This means the business analyst works very closely with the project manager (or product owner) to escalate issues or risks, coordinate multiple teams together, and communicate scope changes or goals to the project team. The business analyst needs to act as the bridge between technical and non-technical project members to ensure the team is on the same page. The business analyst prepares the team for testing and UAT by verifying assumptions and ensuring acceptance criteria are up-to-date. They do this by keeping lines of communications open and understanding the needs of different team members. By working with different members of the team effectively and efficiently, a business analyst can help facilitate a smooth development and project experience.
Boosting Business Analysts Effectiveness
If your company is undertaking an Agile development project, consider how your business analysts could apply these valuable lessons. Business analysts that embrace these approaches will increase their effectiveness during agile development cycles and become more valuable contributors to the long-term success of the project. To learn more about how Credera can assist with your next development project, please contact us.
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
