Invitation Digital Tech Blog

Building Scalable & Responsive Architecture


How to use BAs effectively in Scrum

I have been a Business Analyst (BA) working in agile environments with Scrum for nearly 4 years now, with varying degrees of acceptance and success.

It is a common misconception that BAs are not required in a Scrum team, as the Scrum manifesto does not specifically give them a role. However, we BAs, when used correctly, can and will add value to the process and ensure that the right features are being developed and delivered ‘right first time’.

One of the words I often come up against as a BA in the agile world is ‘blocker’, as in having to deal with a BA is a blocker to getting something developed quickly. In a world where speed of delivery is key, this view can be understood if the stakeholders within the business struggle to understand how using the BA resource can indeed speed delivery and ensure what is delivered is right, and therefore putting an end to rework once a feature is released.

From my experience, the points I have learnt on how to embrace the role of a BA within a Scrum team and how this can help increase productivity and quality are outlined below:

##1. Involve the BA early The earlier the BA is involved in the product roadmap and strategic business decisions the better. This can allow for early, upfront analysis, which will ensure work can be prioritised and readied sooner with the other development team members.

This is beneficial because the early visibility enables user stories to be ready in advance, and with the BA working with the development team, ensures that the team have a clearer understanding of the product roadmap and what work is coming next. The result is work being coded with future requirements in mind, which in turn can enable quicker future changes and cleaner code.

##2. Avoid the proxy product owner trap I have often fallen into the trap of a ‘proxy product owner’, acting as a mediator between the product owner and the development team. This is one of the most frustrating positions a BA can find themselves in.

It results in the BA having no autonomy or responsibility in their role, which as I’m sure you can imagine, does not end up with a happy BA. Instead, if they are not asked to expand their skill set to become the product owner, they should form part of the development team, grooming the product backlog, owning user stories whilst in development and working closely with the developers and testers to ensure efficient delivery and accuracy.

##3. Keep communication open In my opinion, one key skill the BA can bring to a Scrum team is ensuring communication between the business stakeholders and the development team is constant, honest and open. The BA can and should be used as the conduit between the two key parties ensuring everyone is aware of anything that will impact them and helping to clarify any ambiguities quickly and efficiently. Therefore allowing the developers not to be distracted from their sprint commitments, and giving key stakeholders one point of contact and a greater understanding of the development taking place.

This approach will result in the development team having a greater sense of responsibility and ownership of delivering value to the business, whilst the key stakeholders trust that their requirements will be met. Less distraction for the team results in higher velocity and therefore a happy product owner. Win win!

##4. Embrace the traditional BA skill set A true benefit of agile for a BA (well I think so anyway) is the abolition of long laborious requirements documentation. Not only because they take so long to write (and I’m sure no one actually has the time to read them!) but also, because more often than not, they are out of date by the time they are produced.

However, I am passionate about this not meaning the end of thorough analysis. It’s just performed differently, by being broken into smaller, more manageable pieces. A good BAs ability to elicit, understand, document and communicate requirements in a way all parties will understand and agree to is a skill that shouldn’t be underestimated. Of course, this does not mean no one else in the organisation can be involved in the analysis or write user stories (in fact the more involvement from the team as a whole the better, so that there is shared knowledge and a common understanding of what the business is trying to achieve). However the skills a BA has to aid this process, work with others to enhance their skill set, and produce meaningful and concise assets should be embraced by organisations.

##Summary When used effectively, the role of a BA can be just as beneficial to organisations as the traditional BA role in a waterfall environment.

There are many interesting articles out there on how the BA role fits in with Scrum and how their skills can be broadened to help the team even further. Here are a couple of my favourites, happy reading!