Dual-Track Scrum

A framework in which a product development team continuously discover what their customers’ needs are, and validates them using evidence and prototypes.

What is Scrum?

Scrum is an iterative approach that focuses on delivering small units of value and allows requirements to change throughout the project’s lifecycle

What is Dual-track scrum?

Dual-Track Scrum advocates that the product owner/manager, the lead developer, and the UX/UI person constantly spend their time in the discovery space, while the rest of the team concentrates their efforts in delivery. Successful findings from the discovery track are then represented as user stories and added to product backlog.

There are two tracks, each with a different focus but with one aim: to build products customers ❤️

Why?

A Scrum team’s main goal is to satisfy customers’s needs.Pushing user stories into delivery isn’t the end. A product development team’s main goal is to solve customers needs and pain points by building the right product.

The Discover track

The discovery backlog contains items that were hypotheses, which would need to be validated to work out whether something should then go into the delivery track to be worked on by those in delivery.

Brainstorming

The Discover team, comes up with a variety of ideas to help us reach the objective.

Framing an Idea

Example:

Idea title: “Digest email”

1. Why are you building this?

2. Who is it for? (What is the minimal customer group)

3. How will they use it?

4. How will you measure success? (KPIs), e.g. How much are customers willing to pay for what you are developing? How much will retention increase or some other metric.

Validate the value

Hypotheses are validated by using looking at data, talking to customers, and running an experiment.

  • The easiest way to test an idea’s value without building anything? Fake it! Create a dummy version first.
  • Leverage usability testing and investigate if users can understand and the feature.

Moving to Delivery

  • Once hypotheses are validated, user stories are created in the delivery backlog, with a link to the discovery backlog item, to link stories back to their origin.
  • Once a feature has been released, it can then be revisited in the discovery backlog to further validate if the problem identified has been fully solved. We need to be constantly discovering, even on items that had started in discovery and been pushed out to delivery.
  • Everyone attends the usual delivery stand-up (including people in discovery). The delivery are encouraged to attend the Discovery stand-ups and hear what is being discussed.
  • In order to get user stories properly fleshed out, we would have 30-minute refinement sessions every day, straight after the stand-up. Then from 11am. on the delivery team is left alone to work on delivery.

Concluding notes

a more complex, but ultimately a better way to reach your objectives.

Dual-Track Agile looks more messy than the pure delivery track with its factory like nature. With traditional scrum a product manager simply has to select and estimate the time to produce a feature.

Adding a discover track means changing your mindset from delivering feature to reaching objectives.

This looks messy because it is unknown if experiments will be successful

Sometimes upper management may insist on a roadmap because that’s what they’re used to. In that case, I have a few suggestions.

If your organisation expects to see traditional roadmaps or timelines, then you’ll have to disappoint them. With discovery,

For an organisation used to measuring written code and value points, this may create an uneasy feeling of unpredictability.

References