Business Analysis Notes

Case studies

Case Study: An Agile Approach to a Loyalty Program and Billing

4 min read · Updated

In short A start-up abruptly changed its product roadmap, and an analyst had to plan the analysis of two new features while the experts for the more important one were unavailable. Framing the work with the BACCM, choosing an adaptive approach, and cutting scope through a second MoSCoW pass let the team deliver both features in five sprints.

Based on: R. Leyton, IIBA case study on an agile approach (loyalty program and billing), series “How Do I Identify What Needs to Be Done”, 2021; IIBA, BABOK® Guide v3, Business Analysis Core Concept Model.

On this page

This page summarizes a published IIBA case study by Ryland Leyton in our own words. The facts of the case are his; the lessons section adds general practice.

Context#

A start-up changed its product roadmap at short notice. Two new, independent software features were now needed: a customer loyalty program, which had the higher priority, and a self-service feature.

The analyst had about 15 minutes with the product owner, the technical lead and the Scrum Master to plan the analysis. Two constraints shaped everything: development had to start quickly, and the subject matter experts (SMEs) for the loyalty program would not be available for two weeks.

Approach#

The analyst framed the situation with the six core concepts of the Business Analysis Core Concept Model (BACCM) from the BABOK® Guide: - Change: new capabilities for two groups of stakeholders. - Need: internally, speed and no wasted effort; for customers, the specific features. - Solution: two independent software features. - Stakeholders: product management, developers, customers, training, UX and support. - Value: customer retention and competitive advantage. - Context: development had to start quickly.

With this picture, an adaptive (change-driven) approach with only the documentation the team really needed was the natural choice.

What the analyst did#

  • Sequenced the work around availability. The team began with the self-service feature, whose experts were available, while research on the loyalty program continued in parallel. The plan looked six two-week sprints ahead.
  • Ran a MoSCoW workshop with the team to sort the loyalty program’s capabilities into Must, Should, Could and Won’t. On a second review, about 30% of the “Must” items moved to “Should”.
  • Cut scope deliberately. The first release would offer one standard loyalty program instead of a customizable one. According to the case, this brought the loyalty program down to roughly two or three sprints instead of four to six.
  • Grounded the cut in evidence. Interviews with several customers showed similar needs, which supported the standard version.

Outcome: both features were delivered in increments within five sprints, or ten weeks.

Lessons you can reuse#

  1. Use the BACCM as a fast framing tool. When time is short, a quick pass through change, need, solution, stakeholder, value and context gives everyone a shared picture and shows what you do not yet know. It fits on one page and can be done in a single short meeting.
  2. Plan around people, not only priorities. If the experts for the top item are unavailable, start on work you can analyze now and use the waiting time to research the priority item. Make the dependency visible in the plan, with a date to revisit it.
  3. Run MoSCoW twice. A first pass tends to overload “Must”. On the second pass, ask of each item: can we release without it? If yes, it is not a Must.
  4. Look for the standard version first. Configurability multiplies effort. Ask whether one standard option meets most customers’ needs for the first release; customization can follow if real use shows it is needed.
  5. Back scope cuts with customer evidence. A handful of short customer interviews makes a reduction far easier to defend than opinion.
  6. Keep documentation proportional. In an adaptive approach, document what the team needs to build and test the increment, and little more.

Applying it at The Workshop (a fictional bike-repair chain): suppose the owner wants online booking and supplier-integrated parts ordering at once, but the supplier’s IT contact is away for two weeks. The analyst starts with booking, sends the supplier a short list of questions, and runs MoSCoW on parts ordering. A second pass moves “automatic reordering” from Must to Should, and the first release offers manual ordering through the supplier’s portal.

Sources#

  • R. Leyton. Case studies “How Do I Identify What Needs to Be Done” (agile and waterfall approaches). IIBA, 2021: agile approach, loyalty program and billing.
  • IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015: Business Analysis Core Concept Model.