Agile Roles in Practice – To Do or Not To Do ...
Every company ought to include digitalization as a top strategic priority. Since IT (Information technology) nowadays is considered an indispensable part of business, businesses are often confronted with difficulties when managing IT on the one hand and using it optimally on the other (Weber, 2020). In order to meet the changing environment and to manage everything correctly, using an accurate paradigm like the Agile framework is key to improve effectiveness.
In this article, we take a closer look at the role of Business Analyst (BA) on the agile team, specifically within the Iteration Planning (IP) event. As previously mentioned, in the first article of the “Agile Roles in Practice – To Do or Not To Do” series,the key roles such as a business analyst within the Agile framework are logically intertwined with the other roles. And a deviation of these arranged roles may cause some undesired issues.
The role of the BA, in theory, is to hold conversations with stakeholders to understand their requirements and their vision of the product. Then translate those requirements to the other team members and make clear to them the expectations of the project. The BA in this case is the enabler who further empowers the business stakeholder’s critical thinking. It enables the stakeholders to examine more dimensions and provide deeper insights to the agile team.
It is a key aspect to make sure that the requirements are well documented, and that the documentation is up to date. Important for a BA is thus to have good communication with the stakeholders but also with the product owner (PO), since the PO is the one in charge of the product backlog. Moreover, the role of the BA is to split the requirements into smaller user stories, so that the PO can plan it more easily in one iteration.
Several product backlog maintenance problems can arise when the BA accumulates not enough knowledge about the product during the analysis. For example, if the PO tries to take a user story from the product backlog and schedule it without knowing the exact effort, there is a greater chance of spillovers. Moreover, when user stories are planned without being well defined, developers will generate additional questions that cannot be answered in a timely manner, and this can also block the development. Which is a typical issue that may occur.
Based on our field experience, we have observed the following To Do’s and Not to Do’s in the context of the Agile BA role:
| To Do’s | Not To Do’s |
|---|---|
| – Good communication skills and contact with the stakeholders and PO. – Set up a regular review session with the PO, to go over all needed documentation. And to check if all presented user stories are mature enough. – Make sure that the big business need is properly split in multiple doable user stories. – Validate developers’ understanding of requirements and implement a feedback loop to support this during the whole process. | – Put too much pressure on the BA to deliver something that is not quite finished in definition. – Not actively participate in the IP where a lot of questions about effort & product information comes up. – Forget to communicate the level of complexity to the PO, especially when there are dependencies on other user stories. |
In short, the BA has a very important role in refining the product backlog and consequently the IP. More importantly, it all starts with good communication and an understanding of the stakeholders needs.
Want to know more about our expertise within HeadMind Partners? Contact us now!
Weber, A. (2020). The Digital Revolution Is Everywhere. In Digitalization for Value Creation (pp. 15-24): Springer.