Qualities of an Agile Business Analyst

Today’s economy demands a quick response to changing market conditions and customer requirements. In highly uncertain domains, where requirements cannot be predicted ahead of time or where systems need to be delivered quickly to address urgent business needs, traditional software development methodologies are relegated to the background. The Agile software development methodology is based on lean principles and accommodates changing demands or requirements. It is based on the premise that requirements will always evolve and encourages teams to adapt to changes instead of attempting to specify systems completely ahead of development.

This post is a follow-up to Waterfall to Agile: The Role of BAs in Agile Projects and contains a list of the qualities every BA should have (or plan to have) to go “Agile”. 

The Product Owner on an agile team performs functions similar to the BA. The BA may be required to stand in as the customer proxy (where stakeholders are not co-located or where the product owner is temporarily away); assigned the role of the product owner; or required to participate in the team along with the product owner. Whatever the case, every Agile BA should be able to:

1. Work by Collaboration: The Agile team begins each iteration with intensive collaboration aimed at eliciting requirements, providing suggestions and seeking answers that will bring each team member up to speed on what the system is expected to do. As requirements evolve and are fully understood, a more ad hoc interaction takes place. Requirements definition is no longer the sole responsibility of the business analyst and the customer does not stand in the shadows. The BA is expected to elicit requirements through collaboration with developers and the product owner. The BA is also expected to work with the project team to develop realistic and prioritised functional requirements.

2. Deliver Requirements Iteratively: Requirements elicitation is done iteratively on Agile projects. Consequently, the system (or portions of it) is delivered incrementally. As project team members build the system, more knowledge on what is possible becomes available; this knowledge fuels the design of the system. Requirements are thus fine-tuned before each iteration without attempting to define everything upfront. It is also an opportunity for the Agile BA to learn about Feature-driven development.

3. Apply Existing Techniques Differently: The Agile BA is required to promote and apply lightweight specifications in the form of use cases and user stories. Other techniques involving business rules and data models are still used but kept as lightweight as possible. Each user story or use case is further elaborated at the beginning of each iteration.

4. Master Technology & Business domains: The Agile BA is expected to bring a considerable amount of business knowledge to the team and be able to transform knowledge of business requirements into functional specifications. The primary role of the BA is to facilitate communication and understanding between the business and the project team. The greatest challenge I had on the Agile team was understanding developer-speak. All sorts of terminologies flew over my head and this was quite disconcerting. While I'm not suggesting that the BA be able to understand every line of code, the BA should know how the different components of the system interact and visualize what the system would look like when completed.

5. Deliver Requirements at the Appropriate Level of Detail: Agile recommends that “just-enough” requirements be delivered when needed (just-in-time) at the level of detail required to understand and build the system. No more, no less. The Agile team focuses on elaborating only the requirements needed for the next iteration to support their implementation. The Agile BA, in collaboration with the team, thus places more focus on test criteria and examples instead of extensive models and documentation.

6. Transfer Knowledge: The ability to transfer knowledge to the project team is an important skill in the Agile BA. In fact, this is probably the only skill that has the potential to give the Agile BA a strong foothold. The Agile BA should know about business processes, dependencies on existing systems, user problems and shortcomings/mistakes made in the past to proffer advice during decision-making. The product owner and developers are encouraged to partake in analysis and should be provided with the knowledge and skills to do so (in cases where there are knowledge gaps). For example, the Agile BA should be able to explain how use cases work, how user stories are crafted or how the business currently works to the project team.

7. Identify Risks: In Agile teams, requirements that are high-risk are addressed first, allowing the team to mitigate any ensuing problems. Identifying risks early on will ensure that those risks can be addressed to reduce rework.

8. Step out of the Comfort Zone: Remember that Agile team members are “generalising specialists”. The Agile BA thus needs to be much more than an analyst. Agile team members are expected to interact and rub off on each other by asking questions, providing answers or assistance in any capacity required by other team members. Agile BAs should thus be prepared to learn as much as they are prepared to teach.

Loading...

You may also be interested in related articles on Agile Projects.