Guest blog by Ellen Gottesdiener: It’s the Goal, Not the Role:The Value of Business Analysis in Scrum

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn
Ellen Gottesdiener

Ellen Gottesdiener is an internationally recognized leader in the collaborative space where agile requirements + product + project management converge. She coaches, trains, and presents to thousands of people globally and has facilitated hundreds of discovery and planning workshops across diverse industries.
She will hold her popular workshop in Stockholm 25-27 September 2013.

It’s the Goal, Not the Role:The Value of Business Analysis in Scrum

In agile development, what happens to the traditional business analyst? Consider Scrum, currently the most popular agile method. In Scrum, there is no “business analyst” role. In fact, there is not an explicit role for tester, project manager, architect, developer, data administrator, user experience designer, customer support representative, or product trainer. Instead, Scrum has three roles: the product owner, the Scrum Master, and the delivery team. Their collective goal is to deliver high‐valued product needs continually. So, where and how can a business analyst contribute?

One possibility is the Scrum Master role. Great Scrum Masters are facilitative leaders with a diverse set of analysis skills and strong communication and facilitation abilities. In addition, they have a sound understanding of the business domain. Business analysts and project managers with those strong skills are good candidates for the Scrum Master role. Another possibility is the delivery team. On some Scrum teams we’ve coached, the business analyst blends into the delivery team, participating and often leading the activities of planning, analyzing, testing, and demonstrating the product. Using Scrum terminology, that work is burned up and burned down, along with the work of design, development, and so on.

The Business Analyst Is Not the Product Owner, Unless …

The product owner role requires deep domain and product knowledge to guide decisions about what to build and when to build it. The product owner, in collaboration with the delivery team, explores and evaluates product needs to make those decisions. That’s business analysis work.

The product owner may choose to explicitly and transparently delegate decision‐making authority. We’ve seen this responsibility delegated to a business analyst who reports within the business or product management organization and has the requisite domain and product background.

Strategic and Tactical Work of the Product Owner

The product owner role in Scrum is crucial for success. The product owner is responsible for the planning, analysis, communication, and decision making to ensure that the right product is delivered. Strategic product owner responsibilities include:

  • Lead customer and product‐discovery activities.
  • Create strategic product plans and define business value (product profitability).
  • Communicate the product roadmap and plans to internal and external stakeholders.
  • Develop and manage a lean, dynamic product backlog (also called “pruning” or “grooming” the backlog).
  • Select and analyze product backlog requirements to prepare them for agile planning workshops.
  • Identify themes for each planning cycle.
  • Lead or participate in agile planning and retrospective workshops.

Tactical, day‐to‐day product owner responsibilities include:

  • Participate in product backlog grooming (e.g., work ahead, make ready, planning, agile analysis, and pruning workshops) to prepare backlog items for estimating and planning.
  • Specify acceptance criteria for each backlog item.
  • Review and approve user stories.
  • Attend daily stand‐ups and the end‐of‐iteration and end‐of‐release demonstrations and retrospectives.

That’s a lot of responsibility—and it’s time‐consuming, to boot.In addition, most product owners wear many other hats.In commercial software organizations, they may be product managers. Or, in organizations that develop software to support their internal IT operations, product owners may be mid‐ or senior‐level business managers. No wonder the product owner needs help!

Balancing Strategic and Tactical Work

In our experience, many product owners don’t have time to balance the strategic responsibilities with the tactical work needed to sustain a healthy flow of delivery. A time‐ pressed product owner has the following options:

  1. Do it all(sometimes not very well, causing bottlenecks and delays).
  2. Establish a product owner council headed by an über‐product owner, with strategic responsibilities distributed among the members.
  3. Get help with the tactical analysis work. Rely on the folks on the delivery team to do much of the business analysis, and retain strategic and tactical decision‐making authority.
  4. Retain strategic responsibilities and delegate the tactical work to someone else (e.g., a domain‐savvy business analyst). This delegation should be explicitly and transparently communicated to all stakeholders.
  5. Some combination of the above.

Beyond Roles to Goals

After exploring and evaluating requirements options, the goal of analysis is to allocate the highest‐value requirements for delivery. No matter how roles are classified on your agile team, that business analysis work is vital. It is best done collaboratively, leveraging everyone’s skills to build and maintain a shared understanding of product needs. Above all, it’s the goal, and not the role, that matters.

Don’t miss Ellen’s workshop in Stockholm September 25-27

Leave a Reply

Your email address will not be published. Required fields are marked *