Let’s briefly recap what we’re doing here: when a project grows across multiple larger teams, it becomes a challenge to keep all teams and team members on the same page. In previous articles we discussed the importance of balancing refactoring and new requirements, and gave an overview of the 3 practices required to successfully scale a project’s requirements.

The first practice is to communicate the overall vision both clearly and efficient, and in a way sustainable throughout the course of the project.

There are several methods to capture and communicate the vision. Each of them can exist on its own or can be combined with any of the others.

Which method to use depends on the scale of the project. I’ll discus this after explaining the 3 methods.

The vision document

The vision document provides a summary of all the critical elements that should be communicated in order to guarantee a succesful scalable and sustainable requirements setup across the project.

A vision document contains a maximum number of about 20 pages and contains the following elements:

• Expression of the vision: the goal of the product to be built, expressing the end-result for the users/customers, and the objective that the organisation desires to achieve by buidling the product.
• List of features and their benefits/value: this will have to be broken down into user stories later on. The list needs to be high-level but as complete as possible, so that the team can make the appropriate design decisions during their sprints.
• List of nonfunctional requirements: performance, UX, platform specifications, …

The product data sheet

This document is typically a two-pager, containing the high-level essence of the vision document. It can be considered as a summary for sticking to the cork boards in the team rooms.

This document can be enough for the medium-sized projects. It will require the presence of a complete vision document when the project scales up to a very large size.

This is a schematic view of the important elements, in a proposed format:

The vision document and the product data sheet go hand in hand and basically show the same information but serve different purposes because of their different layouts:

• The vision document is a document containing more detail about the different features and requirements, with their respective benefits. It’s a key artifact for very large scale projects.
• The product data sheet is a more schematic overview for quick reference purposes, and is sufficient for medium-sized projects.

The backlog

The backlog can be used by the medium-sized projects and will sound very familiar to the ‘scrummers’ amongst us.

In a small project, the backlog contains a list of user stories that might or might not be iteratively implemented in the final product.

When you need to scale your scrum project, you need to give more attention to the backlog, and the items it contains.

The larger the project, the more important the visibility to a planning horizon beyond the first couple of sprints will be.

In those situations, the backlog will give a high level view on “all the things to come”, so that they can be taken into account during the current sprint.

Only the user stories for the first 2 or 3 sprints are elaborated. The remainder of the backlog contains all the features/epics in an unelaborated fashion.

The product owner is asked to provide a complete list of features/epics prior to the start of the project, so that the full scope can be understood by the implementation teams, and hence avoiding that the sprints will contain too much refactoring.

In order to distinguish this backlog from the classical backlog used in the smaller scrum projects, I’ll refer to it as the “Vision Backlog” from now on.

A small project can have an incomplete backlog at the beginning of the project, or even during the first couple of sprints.

A large project should have a complete backlog containing the user stories for the first sprints, and the epics for all future sprints. This backlog is a complete representation of the product features. Those epics will be elaborated later on, in a “just-in-time manner”.

The vision backlog is the backlog representing the right half of the product backlog.

Conclusions

Difference with waterfall

The above mentioned documents are very different from the waterfall approach, as they lack every level of detail or elaboration. They serve as a ‘checklist’ for all future developments and make sure that there’s a common understanding about the high level objectives of the project.

The 3 above mentioned methods (Vision document — Product data sheet — Vision backlog) should be used when your projects need to scale up.

Method vs. scale

The following image shows which method is recommended based on the relative scale of the project.

Note that the ‘regular’ scrum backlog is only recommended for small projects. This doesn’t mean that you should stop using it when you’re scaling up! The graph only indicates that it stops being an efficient method to express the vision when you scale your project up.

Stefan Luyten

For more information: http://www.triton-consulting.be