Disclaimer: If you’re an orthodox Scrum follower, we advise you to skip this article. 😉 However, if you’d like to know what are the pros and cons of bending the rules of the Scrum Guide, keep on reading.

Scrum Masters have a very important role to play in projects that are being managed in accordance with this framework. They guide their teammates to success and help overcome various hurdles that are encountered during the project development life cycle. However, the reality is that in some cases – especially in smaller teams – it might be hard to justify the inclusion of a Scrum Master to your client.

We think there is an interesting way around that problem – one that might not often be recommended but can nonetheless work very well in actual, real-life circumstances. We’re talking about combining the role of a Scrum Master with that of a Business Analyst. This approach has both some advantages and some drawbacks, but one cool thing about it is that it can be really fulfilling for the person in question.

In this article, we’ll show you how it worked in two of our projects, point out the problems we’ve encountered and things we’ve gained.

Who is a Scrum Master? What does a Business Analyst do?

Scrum Master role

But first, let’s take a few steps back and take a moment to explain who a Scrum Master even is. In the Scrum project management framework, it’s a role of so-called “servant leadership”. A person in this position is responsible for supporting his scrum team, identifying potential problems the project might encounter, and finding solutions for them – ideally before they become a real issue. 

It’s worth noting, however, that a Scrum Master is not a Project Manager, even though a person in this role is usually in constant contact with the client. Scrum Master can be seen as a different kind of leader – one that puts emphasis on freedom and flexibility. The aim is to stimulate and motivate the team. Aside from technical competencies, a Scrum Master needs to have well-developed soft skills – being able to communicate and run meetings is essential.

Here are some things a Scrum Master takes care of on a daily basis (it’s not a conclusive list, though – details may vary from one team to another):

• conducting and moderating Scrum events (daily, retrospectives, etc.), making sure that they take place and are productive
• resolving or escalating blocking issues (e.g. accesses, hardware problems)
• supporting the Product Owner in the area of product backlog management and task scheduling
• motivating team members, supporting them, taking care of their morale
• ensuring that the team and stakeholders work according to the agreed rules and processes
• identifying and implementing solutions aimed at increasing the efficiency of the team
• ensuring that sprint is properly planned (eg. capacity is properly calculated, sprint goal is established)
• informing the Product Owner about issues that can have an impact on sprint realization (e.g. unplanned team member absences)
• verification of the task board in terms of its validity (statuses etc.)

Business Analyst role

Business Analysts are people who work on the border of business (i.e., your client) and software development. Their main responsibility is to help determine the scope and direction of a project. They help plan the basic functionalities and features the software needs to have to fulfill the client’s goals and optimize core business processes. This is done by – you’ve guessed it – analyzing existing documentation, and talking with people (like the stakeholders, client’s employees, etc.) to gather information. Finally, it’s worth mentioning that there are other names for this role – such as System Analyst and IT Analyst. There are some differences between these terms (we won’t cover them here), but the important thing is to know that they’re in use.

Here are some examples of the tasks a Business Analyst usually carries out (again, this isn’t a conclusive list):

• gathering and describing project requirements
• communicating with the client and the development team
• translating business requirements into actual system features 
• creating documentation
• proposing solutions to the client

If you want to know more about business analysis, check our two of our previous articles on the subject. One concentrates on the IT Analyst job description, and the other on the most important and popular Business Analyst tools. Business analysts are very much in demand so it’s worth your time to learn about this role.

Scrum Master and Business Analyst in one – real-life examples

We’ll now show you how we successfully combined the roles of a Business Analyst and a Scrum Master in two different projects.

Magda’s project

Before I combined the roles of a Business Analyst and Scrum Master in this project, I’ve had some experience with management, but it was never a full-time position such as a Product Manager. The move towards Scrum Master happened naturally in my case – the team was self-organizing, and there was no point in hiring a Scrum Master from outside, so I was a natural candidate. It’s worth noting that in the case of my project, Agile is a better description than Scrum. Of course, before I started fulfilling the role of a Scrum Master, I was instructed and trained in this area.

My team was 30 people strong, and in this group, you could find a Project Manager, Analysts, UX Designers, Technical Project Leaders, Testers, and Developers – each of them had only one role (aside from me). On the client’s side, there were 2 Product Owners, as well as over a dozen of employees that our team communicated with. 

In this project, the team was split into two groups – one was more front-end oriented, and the other took care of the back-end (however, this separation wasn’t exclusive – some of the folks were full-stack developers). Sprints lasted two weeks and were separate for each of these groups. Therefore, you could say that, in fact, we had 2 Agile/Scrum teams working on this project.

The work was carried out remotely. The tasks were managed via an online board (through the Atlassian Jira software). When it comes to documentation, we’ve used mockups, diagrams, descriptions and manuals (in Atlassian Confluence). The scope of the work was estimated in work hours. The client was the one who decided whether a task was done (and this decision was made after the scope of the work was evaluated).

We’ve conducted all the Scrum events you typically do in such circumstances. We’ve had dailies with the client and with the team (some of them were obligatory, others voluntary). Reviews and planning happened at the same meeting, once per two weeks. And finally, there were also retrospectives (again, some of them were inside the team, and some also included people from the client’s side).

Paulina’s project

Before taking on the project I want to describe, I’ve had experience with Scrum – I’ve actually helped implement this methodology in another company. Hiring a specialized Scrum Master wasn’t considered in the case of this team – working as both an SM and an Analyst seemed like the best option. 

How big was the project? I’ve worked in a small, 6-person team, with 2 Analysts, 2 Testers, and 2 Developers – though the exact team composition varied somewhat depending on the moment (we’ve always had 2 Developers, but the rest was in flux). The roles were also somewhat flexible – for example, sometimes Developers also took care of software testing. We’ve only communicated with 1 Product Owner from the client’s side. Since there weren’t that many people engaged in the entire endeavor, there was no need to complicate things – we’ve based everything on mutual trust and engagement of each team member. In general, in my project’s case, the work organization resembled Scrum more closely than in Magda’s case. 

Aside from the scope and composition of the team, the main difference between my project and Magda’s is probably the fact that my team worked locally – all of us were in one room. We’ve had a classic, paper Kanban board. The scope of the tasks was evaluated with the use of Fibonacci’s point system, and the points from all the tasks were then counted and presented on the burn chart at the end of each sprint (each sprint lasted a week). It’s important to note that in our case the budget wasn’t being evaluated during the project, and we could make the team bigger at any time if we wished so. We did, however, have a set deadline, which we had to honor.

There were several kinds of Scrum events. We’ve had dailies (real ones – everyone reported on their progress), planning, and reviews on Mondays (presentation was shown, and the manual was updated before planning meetings). We’ve also had optional retrospectives, whenever they were needed. Documentation worked more or less the same as in Magda’s project: we’ve used mockups, diagrams, short descriptions, and the aforementioned manual. However, many things hinged on verbal arrangements between us and the client, which was possible thanks to the fact that we’ve simply trusted each other.

Advantages of combining the roles

There are two main areas that can benefit from having one person fulfilling the role of a Scrum Master and an Analyst at the same time.

Benefits for the project

• Implementing the Agile/Scrum methodology in your project and team comes more naturally when the role is adopted by someone people already trust, as long as that person understands Scrum and has the required skills. 
• Having one person fulfill two roles is always nice because you can either reduce costs or have a spot left for an additional specialist on the team, which will help reduce time to market.
• A broad set of competencies that are required to fulfill both roles can also be a boon in various circumstances. A Scrum Master has a good understanding of the needs of his team and this knowledge can be very helpful for a Business Analyst too. On the other hand, analysis requires a solid grasp of the business goals a given project is supposed to help accomplish, which makes guiding the team in the right direction easier as a Scrum Master. 

Advantages for the person who combines the roles

• While you fulfill both these roles, you can – and will – develop competencies and skills in both areas, including soft skills, which is always a nice thing.
• You just can’t get bored of working like this, because there are different things to take care of all the time. It might seem inconsequential, but it really matters.

Drawbacks and things to consider

There are, however, also some drawbacks of combining the roles. One example is certainly the huge number of meetings you have to take part in, which can sometimes get out of hand. Sometimes things also get a bit confusing because it’s not always easy to draw a line between both roles. For example, you go to a meeting to present your analysis, but the team expects you to lead that meeting as a Scrum Master. 

Another problem is the fact that you can’t spend as much time as you’d like on improving the way your team works, because these work hours are dedicated to the tasks of a Business Analyst. In fact, jumping between different duties can be an issue in and of itself – you often feel like you can’t focus on one thing to an adequate degree.

Sometimes you are forced to make a hard choice between being a Business Analyst and being a Scrum Master, and in some cases, you’ll also need to stay objective – even if that means adopting a point of view your Analyst colleagues might not necessarily agree with. This, in turn, means you’ll need to be assertive.

Was it worth it? Yes!

In the end, we both think that – in some circumstances, and often quite varied ones, as you can see from our very different examples – combining the roles of a Business Analyst and a Scrum Master can be a really good idea. Sure, things can be hard and challenging, but overall it can be a very rewarding experience. We consider it to be one of the most interesting career opportunities we’ve had the pleasure of taking part in, and our projects profited from this approach. We’re not saying it’ll work in every circumstance, but there are many cases where it might. And besides… you know, in the end, Scrum, and Agile in general, is all about being flexible. We believe this also applies to bending the rules of the methodology itself when it suits the needs of both the Agile team and the project.

Do you need Agile developers?

At Pretius we’re very experienced with both main methodologies of creating software: Waterfall and Agile. We have extensive knowledge about many different kinds of projects, and we know how to run an Agile development team effectively. If you’re interested in flexible, talented software development, write us at hello@pretius.com. We’ll be sure to get back to you within 48 hours.