How Vipshop’s Infrastructure Team Adapts Scrum: Roles, Team Size, and Lessons Learned

Background

Vipshop does not mandate a company‑wide development methodology; each team self‑organises. The infrastructure division already practiced Scrum, so the new platform team continued with it. Scrum fits the team because the platform’s product roadmap, release schedule and technical debt are internally driven rather than dictated by external business cycles.

Team Structure

The classic Scrum roles (Product Owner, Scrum Master, Developers) were adapted to the technical nature of the platform product.

Technical Product Manager

The Technical Product Manager (TPM) combines product ownership with technical direction. Responsibilities include:

Gathering functional requirements while evaluating the impact on the platform’s architecture.

Assessing emerging technologies (e.g., containerisation, Mesos) for suitability and cost‑benefit.

Prioritising technical debt alongside feature work.

Coordinating with upstream development groups using a technical‑first communication style.

Driving roadmap decisions based on both business value and system performance.

Scrum Master (Distributed)

The team found a dedicated Scrum Master to have low perceived value. Instead, Scrum‑related tasks such as maintaining the task board, facilitating planning games and removing impediments are shared between the TPM and the Development Leader. This distribution keeps the process lightweight while preserving Scrum ceremonies.

Developer Leader / Architect

The Development Leader (often also the system architect) is responsible for high‑level design, ensuring that the architecture aligns with the product roadmap, and guiding the developers on implementation patterns. A key risk is over‑loading this role; if the leader spends most of the time firefighting, architectural quality degrades. The rule of thumb is: *product decides what to build, architecture decides how to build it*.

Tester

Although Scrum encourages developer‑owned testing, the team retains a dedicated tester to:

Design test points (functional and non‑functional) and ensure coverage of performance, stability and scalability.

Bridge gaps in testing expertise, especially during the transition from traditional waterfall to Scrum.

Drive automation effort and integrate test suites into the CI pipeline.

Developer

Developers are expected to produce production‑ready code and also contribute to automated testing, performance profiling, and continuous integration. The role therefore extends beyond pure coding to include test design and quality advocacy.

Staffing Ratio

Empirical experience showed that a seven‑person team provides a good balance of self‑management and effective delivery. The recommended composition is:

1 Product Owner (Technical Product Manager)
1 Architect / Development Leader
3 Developers
2 Testers

This 1+1+3+2 configuration avoids the communication bottlenecks that arise in overly fragmented or overly large Scrum teams.

Project Management Considerations

Scrum focuses on product outcomes rather than discrete projects. For large‑scale initiatives (e.g., company‑wide events) a separate project manager may be introduced to coordinate multiple Scrum teams, but it is not a core requirement for a typical platform team.

Conclusion

Clear definition of responsibilities—technical product management, distributed Scrum facilitation, architectural leadership, dedicated testing, and developer quality ownership—enables a high‑performing Scrum team in a technical platform context. Emphasising automated testing and technical debt management is essential for sustaining product quality and velocity.