I recently kept getting asked the same question while at a conference for business analysts and project managers in the Boston area. The question went something like this: “I’m a business analyst and my company is moving to agile and scrum, do I still have a job?”

My quick response was there is always room for business analysis in agile and scrum. However, your title might be different, and your responsibilities might change. You might even have opportunities to do other things, if you’re interested and have the skills to do them.

The role of business analysis definitely exists and is needed no matter what framework, method or process you are using. It is often thought that in scrum, the business analysis function is the sole responsibility of the product owner, but that isn’t generally true.

The Product Owner

As defined in the Scrum Guide, the product owner is responsible for maximizing the value of the product resulting from the work of the development team. How this is done may vary widely across organizations, scrum teams and individuals.

The product owner is the sole person responsible for managing the product backlog. Product backlog management includes the following:

  • Clearly expressing product backlog items.
  • Prioritizing the items in the product backlog to best achieve goals and missions.
  • Optimizing the value of the work the development team performs.
  • Ensuring that the product backlog is visible, transparent and clear to all, and that it shows what the scrum team will work on next.
  • Ensuring that the development team understands items in the product backlog to the level needed.

The product owner may do the above work or have the development team do it. However, the product owner remains accountable.

The product owner is one person, not a committee. The product owner may represent the desires of a committee in the product backlog, but those wanting to change the priority of a product backlog item must go through the product owner.

For the product owner to succeed, the entire organization must respect his or her decisions. The product owner’s decisions are visible in the content and ordering of the product backlog. No one can force the development team to work from a different set of requirements.

Related Article: Agile, Kanban & Scrum, Oh My: Which Product Management Method Is Right For You?

Is the Product Owner the Only One Doing Business Analysis?

Product owners certainly do business analysis, but they don’t have to work alone. Often, one person cannot know everything and must rely on others for guidance. Having a single, accountable, empowered person (the product owner) gives the rest of the people in the organization a focal point to drive what is needed as they work with the team to deliver on needs.

To deliver the right product features to market in a way that provides value to stakeholders, both customers and the organization, the product owner must work with the development team to provide business analysis, subject matter expertise and broader clarity of what the team needs to deliver. But the product owner is not alone.

Who Else Does Business Analysis?

Other people besides the product owner can do business analysis. In fact, anyone who needs to do business analysis can do it.

Learning Opportunities

Of course, that observation doesn’t provide very clear guidance about who should be handling business analysis. In scrum, teams self-organize; team members work together to determine how their teams should accomplish their goals. Responsibility for business analysis will be handled in whatever way the team feels is best. The development team may decide that one person should focus on business analysis, or that responsibility for business analysis will be spread across the entire team. Or it could come up with another option altogether.

The product owner could also choose to rely on others from outside of the scrum team for business analysis. There may be other services within the organization that provide subject matter expertise as part of the effort. People with subject matter expertise may even be brought into the scrum team at some point, depending on the scenario.

When we start thinking about lean user experience and concepts around user experience and user interfaces in general, it is clear that those activities, too, can live within the scrum team.

There is no better way to prove out concepts than to build and test them with users and stakeholders. I have been part of many initiatives where users saw a picture of something and loved it, but then found it far below their expectations once it was built. Once they started to really use the product, they found that it didn’t do what they expected. And we all have seen examples of products that aren’t used in the way we had expected once they are in users’ hands.

Related Article: Don't Go Chasing Waterfalls in Your Software Projects

There Is Always a Need for Business Analysis

Business analysis is a critical skill to ensuring that we deliver the right thing to users and bring value to customers and stakeholders. We must understand our users and look at things from the outside in, not from the inside out. However, the way teams go about doing all of that can vary.

When working in an agile manner and using scrum, you shouldn’t stop doing business analysis. The job title “business analyst” doesn’t matter. Business analysis needs to exist and becomes just as critical as ever. Product owners may be ultimately responsible, but an individual product owner is just one piece of the overall puzzle. Product owners could use help from others, including subject matter experts and people who are close to the users, to ensure that value is being delivered.

So, don’t worry if you are a business analyst being told that you are now agile. Your organization will still need your skills, and it will for a long time.

fa-solid fa-hand-paper Learn how you can join our contributor community.