I recently took the Scrum Master course and certification. If you work in software development in any capacity and you have the chance, I recommend you take this course, even if you aren’t a proponent of Scrum itself. Approach it with an open mind and you’ll come away thinking a little differently about managing people. I’m not saying you’ll be an Agile convert, but it will make you re-examine lot of the fundamental assumptions of traditional project management.
As a business requirement specialist, I was particularly interested to see how an experienced analyst might fit into Scrum. I had read a couple of books on Scrum, Kanban, and other Agile topics but I found them somewhat vague when it got to the nitty gritty details. The frameworks are meant to improve management of people, product and schedules and provide development teams with an environment where they are more able to adapt to change. The details of how you write code, elicit user stories, conduct tests and manage builds are left to the organization or team to work out. Most development teams find that Extreme Programming techniques such as TDD, continual builds and paired programming fit well into Scrum and Kanban. However, I couldn’t find much information on how best to interact with clients, which is the role of the business analyst in a traditional project environment.
The Agile Manifesto Principles state that face-to-face communication is valued over documentation, and Agile projects prefer to keep documentation lightweight and just-in-time rather than complete and comprehensive records built up-front. However, whether you’re meeting with them regularly throughout the project or emphasising their involvement in the early phases of development, using your clients’ time efficiently is a critical part of keeping them involved. If you’re not able to keep them involved, your project is likely to run into issues regardless of what project management framework is applied. This is what business analysis, at its core, is intended to do. Organizations often lose sight of this in the creation of templates and processes, but analysts should be applying techniques that enable them to understand and communicate client needs and maximize the value produced in the time clients have available. Therefore, I see the role of analyst still being critical to success in a Scrum environment.
So, the next question is which of the Scrum roles would best suit a business analyst? Scrum defines 3 roles as part of the Scrum team – Product Owner, Scrum Master, and development team member.
The primary responsibility of the Scrum Master is to enable the team to maintain or improve their velocity, meaning the rate at which they complete user stories, by removing impediments that are hindering the team. For most business analysts, this might be a difficult role to fit, as many impediments that teams face are technical and possibly out of the analyst’s area of knowledge such as the builds in the test environment are taking too long or there are technical debt issues that need addressing in the code base. Other issues may be more managerial, such as the team is missing a key skillset or a member of the team is unavailable for a length of time. There is no reason a business analyst could not become a scrum master, but the responsibilities of a scrum master are more in the area of project and people management than business analysis.
The product owner, as defined in Scrum, manages the product backlog, which is the list of user stories that are ‘on deck’ for future sprints. The product owner works between the client and the technical team, breaking user stories down, getting more detail where needed, and prioritizing the user stories. They also work with the development team in order to ensure that each sprint delivers value to the business.
This role seems like a natural fit for a business analyst. The product owner translates business need into user stories, analyzes information and drives out more information where needed. However, the product owner has to have the knowledge of the business and the authority required to make difficult decisions about business value and priority. Most of the very effective analysts I know are effective because they draw out information and facilitate decision making rather than make difficult calls like this themselves. Organizations like the IIBA have also emphasized that business analysts should be experts in analytical techniques rather than experts in the business area. So, while this might be a more natural fit than a scrum master, moving to a product owner role may be a major adjustment for some analysts, and an even bigger adjustment for some organizations in that they have to empower their analysts to make business critical decisions.
I have heard of teams employing a business analyst as a development team member. Their responsibility is to maintain the Agile Specification, which is a living “just enough” requirements document. This requires finding out what additional information the developers need on a user story, getting the information from subject matter experts and recording the information in the specification. They may also contribute to testing and identifying when a user story meets the definition of done, and act as a proxy for the product owner as the developers uncover the things they didn’t know they didn’t know.
This is an extremely valuable role, because for high velocity teams the product owner can quickly become a bottleneck. With an analyst looking into the details the team needs, the product owner can focus more on grooming and prioritizing the backlog and communicating with stakeholders. If the organization is scaling Scrum and has multiple teams working concurrently the analyst can also act as a liaison between the teams.
It’s not a perfect fit however. Analysts in this role need to have skills in many different areas, from enterprise analysis to user acceptance testing. They need to be able to recognize where their work is needed and where it isn’t and adapt accordingly, rather than reviewing and completing a template. The business analyst must also recognize that the document is not the preferred way of communicating with the team. Even an Agile Specification is just a starting point for face-to-face communication, or a reminder of a previously held discussion. Here is an article describing the challenges analysts face when moving from analysis in plan-up-front development, ie waterfall, to an agile environment.
So, if you’re starting a project or transforming your organization into Scrum, you’re wondering which role analysts should play. I think either the product owner role, if the organization provides them with the authority and information needed to make decisions, or a team member, if the development team is high performing or the project is complex. If I were asked, I’d probably recommend keeping them as a team member at first, and then re-assessing as to whether they can or want to play the product owner role.