We have seen in part 1 that there’s a critical balance between the amount of refactoring, and the number of new requirements that can be implemented during a sprint.

Not enough refactoring leads to an unstable design, and too much refactoring leads to insufficient value production at the end of the sprint.

In this article, I’ll give an overview of 3 practices that can be applied in order to scale your agile requirements for larger projects.

The 3 practices highlight 3 different aspects of the scaling method:

• A time-independent aspect, setting a stage at the beginning of the project, and remaining unchanged throughout the course of the project, acting as a beacon while on the road to the end-result.
• A time-dependent aspect, guiding the team throughout the course of the project.
• The toolset, or mechanism, for the scaling method

The 3 practices are:

1. The time-independent aspect : Vision
2. The time-dependent aspect : Roadmap
3. The mechanism : Just-in-time elaboration

Vision

A clearly expressed vision will guide the teams through the project and provide a background for understanding the requirements, and later on, the elaborated user stories.

The vision provides the common purpose for the teams throughout the project. The larger the team, the more important the support of a holistic vision

In a large multi-team project, the vision is critical as it provides a common baseline for all project-related developments across all the teams involved.

The vision is also used to convince higher management of the value-proposition and provides the foundation for future product-related marketing activities.

Roadmap

To set priorites when implementing the vision, a product roadmap will describe the vision on a release-by-release basis. It describes the planned evolution of themes and features over time.

While a sprint works with a planning horizon of a couple of weeks, the roadmap works with a typical horizon of one year.

For the larger agile teams, the roadmap is a key artifact of the agile process, and deserves a place on the wall of the team rooms.

Just-in-time elaboration

Both the vision and the roadmap play at a fairly high level of abstraction: the feature level. This 3rd practice, the practice of just-in-time elaboration, translates the features to the individual user stories that can be used by the team.

Since we’re being agile, the elaboration of features need to happen ‘just-in-time’; because we want to invest as little as possible until such time as actual implementation begins. Agile’s goal is to invest in code and not that much in requirements documentation.

When the elaboration is not ‘just-in-time’ the teams run the risk of falling back into the ‘waterfall way’ of describing requirements. This means that requirements are elaborated in too much detail and too early in the process, without the actual implementation already visible on the horizon.

In the next article, I’ll cover Vision.

Stefan Luyten

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