Mastering Product Development Rhythm with Scrum: Iterations, Backlog, and Roadmaps

Author Background : Qi Gechuan, product manager for distributed service framework, scheduling system, and container management platform at Vipshop, with 16 years of IT experience and a focus on Docker and Mesos.

1. Product Development Rhythm

In Scrum, the Backlog, iterations, and Planning Game are key. For production‑grade products we run a 5‑week major iteration: two‑week mini‑iterations followed by a final week for summary, next Planning Game, and release activities. For development‑only packages (e.g., Maven artifacts) we use a 4‑week major iteration with two‑week mini‑iterations.

Each major iteration must end with a releasable version.

When external events (e.g., Double‑11) arise, prioritize high‑impact items to keep the version releasable.

Version management is discussed elsewhere; the key is that a product without a releasable version is effectively finished.

The goal of every major iteration is a runnable product that delivers new value to customers.

Backlog management can use simple tools (Excel, Wiki). Contrary to intuition, not every high‑priority item should be selected for a major iteration; having more than three high‑priority items dilutes focus.

Product managers should limit themselves to 2‑3 truly top‑priority items based on half the team’s capacity, supplementing with “improvement” items that can be adjusted as needed.

The Planning Game’s biggest impact is thorough upfront preparation—understanding requirements, architecture, and risks—so the development rhythm stays stable.

2. Defining the Product Roadmap

A roadmap visualizes the product’s vision and major features over its lifecycle, similar to a person’s growth stages. Release Management, by contrast, describes when the product reaches specific milestones (e.g., version 0.0.1).

The author prefers a fish‑bone diagram to map feature evolution, mixing roadmap and release concepts (see image).

3. Requirement Management – Backlog

Some organizations also maintain an MRD (Market Requirement Description) expressed as a user story without implementation details.

Backlog items are finer‑grained than MRD and may include user stories. The author’s team stores backlog entries in a Wiki table with the following fields:

id – unique requirement number

title – short name

description – detailed description

priority – importance level

feasibility study – need for analysis

solution – need for architecture/design

review – need for review

status – current state

action – target release version

Before each major iteration, the product manager reviews the table with stakeholders (leaders, business reps) to align on understanding and priority.

Work tasks are not the same as backlog items. A backlog represents a large feature; it is broken down into tasks such as front‑end work, back‑end work, test case design, performance testing, etc. The team uses GitLab issues for task tracking, referencing the issue ID in commit messages (e.g., #123) so code reviews can be linked to the corresponding requirement.

Task granularity is an art: too fine makes coordination cumbersome, too coarse hampers tracking. A three‑day work chunk is a good reference; for less mature teams, keep tasks within one day.

4. Development and Testing Collaboration

Communication is paramount; avoid letting tools replace direct conversation.

Both development and testing should obtain requirements from the product backlog, not from ad‑hoc requests.

In Scrum, roles blur: developers write test cases, testers contribute to test case development, and testers focus on designing comprehensive test points that surface hidden requirements or edge cases.

Testing should provide fast feedback (e.g., assess performance impact within 30 minutes of a new feature).

Developers should review test point designs and alert testers to potential regression risks when code changes.

The author concludes with a personal maxim: “Development drives testing, and testing drives development.”