It’s the Goal, Not the Role: The Value of Business Analysis in Scrum
“Business analyst” is not a distinct role on Scrum or other agile teams. And yet, the goal for the team—to deliver high-valued product needs—requires strong business analysis skills. Ellen Gottesdiener and Mary Gorman describe the vital analysis work needed reach the goal, regardless of role.
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 ScrumMaster, 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 ScrumMaster role. Great ScrumMasters 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 ScrumMaster 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 analystwho 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:
- Do it all (sometimes not very well, causing bottlenecks and delays).
- Establish a product owner council headed by an über-product owner, with strategic responsibilities distributed among the members.
- 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.
- 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.
- 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.
Resources
Product Owner Role
- Pichler, Roman. Agile Product Management with Scrum: Creating Products That Customers Love. Addison-Wesley, 2010.
- Schwaber, Ken, “Product Owners Not Proxies.”
Agile Analysis
- Gottesdiener, Ellen and Mary Gorman, “Agile Planning and Analysis: Synergizing to Deliver Value,” Better Software, May/June 2011.
- Gottesdiener, Ellen and Mary Gorman, "Slicing Requirements for Agile Success," Better Software, July/August 2010.
- Gottesdiener, Ellen, "Agile Business Analysis in Flow: The Work of the Agile Analyst (Part 1and Part 2)," Modern Analyst, May 2009.
User Comments
14 years ago (or so), I participated in an agile-scrum group that implemented a hybrid, lean-agile methodology and focused on agility more than doing an agile process. This department was able to double programmer productivity almost immediately—but there was some temporary stress increase as the change from waterfall to agile was made—they were able to produce a User's Guide for each feature while the programming and QA was happening, and they were able to release features most needed by customers in a truly agile and quick manner. They accomplished this by the following practices and some others:
An analyst prepares some ideas for a project's features and then schedules a meeting (Feature Blitz) where all the development team [domain expert(s), programmer, code reviewer, SQA engineer, the analyst, and any manager that really wanted to attend] decide the features needed, their specs, their implementation, the proposed order they will be coded and list of dependencies, breaks them into iteration-sized mini-projects, and at the end of the meeting assigns people to each of the above roles for each mini-project. The specs are the notes and digital photos from this meeting. Next each member of the team enters estimates of hours for them to finish their role's work for each iteration or mini-project. The managers, in Iteration Planning, then swap around any resources or mini-project to maximize the use of everyone's time, keeping in mind that changes may require the new team member to meet with the analyst or others to get up-to-speed on what happened at the Feature Blitz and that the new team member may not be able to do the role's work as fast as the one who helped decide the particular implementation in the Feature Blitz. Next there is a commitment meeting where the development team (the four roles besides domain expert) commits to their deadlines even if they have to do overtime, which rarely happened because people became good at estimating their work ability. Simultaneously during an iteration, the analyst writes the User's Guide, the QA engineer wrote a test suite with corner cases and exceptions that programming may not have thought about, the programmer and code reviewer discuss the details of the implementation and do the coding. Obstacles and progress were discussed frequently among the whole team and communicated to management and other stakeholders. QA tested each code drop so a programming path that wasn't going to work was caught quickly and little code had to be thrown out. QA had enough time to do their job properly and checked how the feature functioned with other features. Analysts, QA, programmers, and domain experts generated other enhancement ideas not only for the project, but for other projects as there was more time for exploratory testing, prototyping, and thinking about the entire product/program. At the end of the iteration, the released product was more closely bug-free than the waterfall methodology. Lastly, QA had test suites that could be assigned in the future to other QA members or customer support for re-testing prior to each product/program release.
IN SHORT, EVERY SCRUM TEAM SHOULD HAVE A BUSINESS ANALYST. THEY ARE A VITAL PART OF THE TEAM.
1) Scrum DOES NOT have a BA role. The BA should assist the PO outside the Scrum Team.
2) QA doesn't mean testing. That's called QC.
"An analyst prepares some ideas for a project's features and then schedules a meeting" :) that's not Agile
richard, most agile teams don't focus on roles as much as you describe in your 14+ year ago experience, sounds like a good deal of handover and role differentiation.
dan: as i see it, analysis skills (and domain knowledge) are needed on the development team (among many other discipline and skills), they don't' need to be embodied in one person. i don't agree that the BA "should assist the PO outside the team". i do agree with your comment that quoted Richard, that that is not agile ;-)