The business analyst has become a mainstay of the modern IT project, as many a veteran will tell you that you leave the BA (business analyst) on the side lines at your own peril. In a traditional Waterfall project, our roles as business analysts are well-trodden ground. Eliciting, documenting, and validating requirements, mapping business processes, and acting as a link between external stakeholders and development teams are key roles that business analysts will cover on any Waterfall development project. However, in a 2015 survey of industry professionals, Hewlett Packard found that Agile projects are now the norm*. The vast majority of organisations are now using some form of Agile as the primary methodology across their development projects. So, the question of the BA’s role in this brave new world is now more important than ever.
At Software Solved, we use the Scrum methodology in our Agile approach to software development. Although it’s one of the most popular Agile frameworks used throughout the industry, Scrum does present a peculiar problem to BA’s – the position of the Business Analyst in the official Scrum team does not exist. Like many Business Analysis teams before us, once we’d recovered from the initial shock of being left out, we set about defining what the BA in Agile development means to us here at Software Solved.
While the named role of ‘Business Analyst’ might not exist in the official Scrum literature, the responsibilities that a BA will cover are still present, albeit split roughly over two roles. The first role is that of a member of the development team. The Business Analyst will still gather requirements for the project, writing them into user stories as to keep the core value to the users at the heart of each new feature. It is then the BA’s responsibility to communicate these stories to the wider development team, ensuring that there is understanding and consensus from all parties. Being embedded closely with the technical experts helps us bridge the gap between the business goals of the project and the delivered solutions.
Working closely with the development team is one of our key responsibilities as Business Analyst’s working in an Agile framework, but we also tend to overlap with another role – the Product Owner. Product Owner’s will be in charge of managing the project backlog, directing the priority for feature sets, and making sure that the project brings real value to clients. Here at Software Solved, the BA on the project will work closely with the client to fulfil this role, taking backlog management and prioritisation as a shared duty, rather than acting as a proxy.
Even though we have our feet in two Scrum camps, the Business Analyst still has a vital role to play in the Agile development process. Communicating business needs between external and internal stakeholders, eliciting and documenting requirements and making sure projects deliver value for clients are at the heart of everything we do as BA’s, whether we’re involved in an Agile or Waterfall project. Understanding the context and good communication skills are part of the Software Solved BA ethos, which we bring to all our projects no matter the methodology.