A question that has been on a lot of Business Analyst’s minds, BA discussion groups, blog posts, and conference hallways is “Where do business analysts fit in agile projects?” There have been a lot of answers provided so far, many from people who have been practicing agile but wouldn’t call themselves business analysts, and several others from folks that are proud to call themselves a Business Analyst, but haven’t had much experience in agile. Finally there have been a few that have put forth ideas from a perspective flavored by experience in both agile projects and business analysis. I’m going to add my thoughts as a member of that third group.
Where do Business Analysts fit?
The Scrum approach prescribes three roles: Product Owner, Scrum Master, and the Team. Specific roles such as tester, developer, project manager, architect, system analyst and business analyst are not explicitly mentioned. The reason for the small number of roles is to move the emphasis from a group of specialists working on clearly delineated tasks to a team of people working together to solve a specific business problem. At their core, the three roles in Scrum correlate to the main responsibilities in project work:
- Product Owner – Business leadership: what business problem is the project trying to solve?
- Scrum Master – Process guidance: is the team working as effectively and efficiently to solve that problem?
- Team – Technical delivery: applying the right technology to solve the problem.
To help break down the “business vs IT” divide, I think of the team as being everyone who is primarily focused on the project during a given period of time. This means that the project team includes both IT and business folk working together. So the simple answer to where do business analysts fit is the Team. The more interesting question is: what does a business analyst do on an agile project?
If you consider a typical agile approach, take Scrum for example, there are several ways that business analysts can add a great deal of value. I categorize those ways into three groups:
- Grooming the Product Backlog
- Acting as a Business Coach
- Being a good team member
Grooming the Product Backlog
Most agile approaches start with the assumption that the list of things to do, the Product Backlog in Scrum vernacular, already exists. The creation and maintenance of this artifact, fairly critical to the success of the project, is the responsibility of the Product Owner. The Product Backlog at first glance looks fairly easy to create and keep up to date. It is, after all, a prioritized list of things to do. The key is making sure that the prioritized list of things to do fully describes the appropriate solution to the problem. This is where business analysts can add a great deal of value.
To ensure a truly valuable product backlog, you want to have an understanding of the context in which the problem exists. Requirements models such as process flows, domain models, a glossary, business rules, and context diagrams can help describe the overall problem and solution space. They are also reference points from which the individual product backlog items or user stories are derived for inclusion in the Product Backlog. The value of these models comes not from the documents themselves, but rather the process of creating them helps the team develop a joint understanding of the domain and ensure that the team does not lose the forest of the overall problem space in the trees represented by the users stories on the product backlog. Shane Hastie shares some similar thoughts in this blog post on InfoQ.
The ideal Product Owner has a combination of analysis skills and decision making authority. Analysis skills to facilitate discussions about the problem space and knowledge of how to use requirements models to describe and verify it with stakeholders, and decision making authority to determine which aspects of the solution to deliver in what order.
In reality, most Product Owners have one of the two. If that is the case you want someone in the position to have the appropriate decision making authority, and not be afraid to use it. Decision making authority is more important because a lack of effective decision making will have a huge negative impact on the success of the project. The analysis skills can be supplemented, which is where business analysts come in. BA’s can play a key role in helping the Product Owner establish a clear understanding of the problem space and create a meaningful and complete Product Backlog.
So can a business analyst be a Product Owner? Sure, if they have the appropriate decision making authority. Experience has shown that most people with the title of business analysts when on a project team are working in an advisory or consultative function and are not in a position where they will be using the results of the project on an ongoing basis. That responsibility usually falls to the leader of the organization that will use the results of the project who are typically the project sponsors in non agile projects.
Acting as a Business Coach
The user stories contained in the Product Backlog are intended to be reminders for further conversations and are not intended to fully describe the actual thing that needs to be done. Because of that, some analysis may need to occur during the sprint in which the user story is being delivered. Considering the short amount of time available to understand, develop, and test a particular user story, the team wants the most effective process possible to get from user story to delivered functionality. Since the team includes both subject matter experts and developers, there is no reason why developers working on a particular user story shouldn’t work directly with the subject matter experts most familiar with that user story.
Chris Matts described the idea of a Business Coach in a blog post, and I think it is a good description of what people with business analysis skill sets do during the sprint. To summarize what Chris described:
- Facilitate collaboration between members of the team
- Generate examples to describe the specifics of the users stories
- Transfer knowledge about the problem and solution to the rest of the team
Chris mentioned that business analysts should focus on generating examples rather than developing models. I believe there is value in both. As I mentioned above, models are useful for describing the overall problem space and putting things in context and examples are best for communicating the specifics to the rest of the team, plus they make great starting points for testing.
Being a good team member
The thing I like the most about agile approaches is their focus on team work. While I enjoy solitary work as much as the next guy, being able to work on a team and getting the opportunity to learn and exercise new skills outside of my normal job responsibilities is very exciting. Most agile teams that function at a high level practice self direction, which among other things means that they determine among themselves who is going to work on what at any particular time. Generally this means that people will select tasks best associated with their particular skill sets, but there will be times where team members can help others out and get the opportunity to do a task they would not normally do.
These situations pull the team closer together, and gives everyone on the team an opportunity to learn a new technique or skill. Aside from the short term benefit of making the team more successful overall, it also makes the individual team member that much more valuable on the next project, the next consulting gig, or the next job. Organizations still look for specialists, but they want specialists who have a bit of flexibility. If you are able to continuously expand your toolkit, you will be more valuable to future clients or employers.
Raising analysts to a higher level
So if you take a look at it, working on an agile project allows business analysts to do the things they should be doing. Once we remove the perceived need to act as a go between for “the business” and IT, and to document all of that information to the nth degree, we are left with working as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals which – as it happens – is the definition of business analysis in the BABOK. Agile approaches clear away many of the tasks that I think have been preventing business analysts from adding as much value as they could.