At DVT we run regular online events that are focused on the latest technology trends within the IT industry and we invite guest speakers to share their knowledge and insights on various topics. The DVT Insights Events aim to enlighten you, educate you and often, provide a new view on a burning issue within the technology space.

Are Agile teams a blessing or a curse to Business Analysts?
Deidre Forbay
Senior Business Analyst, DVT

Are Agile teams a blessing or a curse to Business Analysts?

Wednesday, 09 May 2018 11:29

Is there a future for Business Analysts in an Agile world? This question has been raised by many BAs recently and for good reason. In many Agile frameworks, we don’t find any mention of the Business Analyst. It is not that they don’t recognise the need for analysis, but rather that anyone on the project should be able to do it. I am of the opinion that business analysis is not something you can do on the side while you are busy with development or testing. So my answer is YES! We are now more relevant than ever before, and organisations finally realise that we are not document writers.

However, am I merely denying my own “extinction”? Strangely enough, it is in Agile environments that I find confirmation of the importance of having a Business Analyst on an Agile team.

As a child, I was known to some in my church leadership as “the WHY child” because I questioned everything. Unknowingly, this was a prelude to what my career would be about: WHY? BAs must always ask “Why, why, why?” and in Agile projects, this is one of the most important questions together with your skills to ask the correct probing questions so that you can learn fast and fail fast.

The IIBA Global Business Analysis Core Standards (2017) states that BAs are responsible for, amongst other things, to “clarify their (customers’) expressed desires – in order to determine underlying issues and causes”. I would imagine that it would be challenging for a developer to fulfil his daily duties of writing code, unit testing and sometimes learning new technologies as well as performing this vital business analysis task on a daily basis. Yes, on a daily basis because we have to question each user story to ensure that whatever the story delivers, still adds value to the business or customer and that it aligns with the project and organisational vision.

Scrum Product Owners are typically overly busy on more than one project and are often not one hundred percent allocated to a project or team. But the work of the PO still has to be done: the team still need guidance on what to deliver when. So who better to fulfil the role of a Proxy Product Owner other than the analytical, yet vision-focused BA? I’m not for one moment suggesting that no-one else on the team can do this, barring of course that they have the necessary skills. BAs and POs are a match made in heaven! They have the same skill set, and both players must at all times focus on the field and the ball whereas everyone else in the team just plays the ball.

Part of the BA’s job is also to make sure that the team can continue with their respective tasks during the sprint and not have to wait for an unavailable PO to clarify queries the team may have. This is why the team should have a BA that is part of the development team and is co-located with the delivery team while maintaining a close relationship with the PO to ensure a common vision for the product or project.

The BA can also be an asset to the UI/UX expert who will typically not know the hidden business rules of each functional requirement. Having clarity on the business rules up front will help the team progress faster and avoid unnecessary back-and-forth between the PO and the team or even the end user. Clear business rules are especially valuable during the design activities when the user interface is created as these screens are used as input by the developers and guidelines for testing.

This also makes the BA the ideal candidate to assist the QA team with queries they may have around the acceptance criteria. Sometimes, even well-defined requirements and test criteria may be unclear to some team members. And of course, the added benefit of having a BA on the team is that you have an extra hand to assist with testing. When the project budget is tight, testing is often the area most vulnerable to failure as quality assurance testing becomes a lower priority to the team because developers are expected to do unit testing. Unit testing is never a substitute for quality assurance testing, though.

So to answer my own question: Are Agile teams a blessing or a curse to Business Analysts? My answer: Neither. Business Analysts are a blessing to Agile teams. BAs are by nature cross-functional as well as analytical human beings, and that makes them perfect for Agile teams.

Published in Business Analysis
DVT 25 Years of Service