Building Upon Itself

The famous Mendelbrot Set fractal

At the core of team-based Scrum management practices is the Sprint, a 2 - 4 week iteration which results in an increment of software which can be demoed or released. Like a fractal, the Sprint can be scaled to a product roadmap with several stops in between.

What is a fractal? It’s a geometric shape built from smaller versions of itself.  This shape then becomes one piece in a larger version of itself, which in turns makes up an even larger version… and so on.

Can the Sprint, complete with its adaptive planning and just-in-time elaboration of detail, build upon itself? The answer is yes. However, in enterprise planning the reverse usually happens: the product roadmap it broken down after strategic planning takes place.

Sprint to Roadmap, Roadmap to Sprint

The terminology for taking a roadmap and breaking it down to the Sprint level after setting (or reviewing and adapting) the strategic plan provides the foundation for my next blog posting on the Agile Requirements Breakdown Structure (RBS). Since a picture is worth a thousand words, let’s let an image show the relationship between sprints, releases, projects, and roadmaps:

From Sprint to Roadmap

The Roadmap

The roadmap comes out of the strategic planning process and provides the vision for a software product or application. For smaller applications, it may look only six month into the future. More complex applications may have a three year roadmap. Keep in mind that an agile enterprise will review and adapt the roadmap periodically, often in conjunction with the budgeting process.

The Project

Roadmaps break down into projects. At this level, the business case is made, often in the form of a project charter. ROI is forecasted and budget approvals takes place.

The Release

Projects break down into releases. Releases result in the internal or external release of a version of software. Before software is released, heavy “hardening” takes place to test business logic, code integrity, scalability, and the other “ities” like security and usability.

The Sprint

Releases break down into Sprints. Sprints result in demos to gather feedback from constituents and to keep the business engaged. Lighter hardening takes place to balance the value of early testing with the cost associated with heavy hardening.

Round-trip from Sprint to Roadmap

Though decomposition from the higher to the lower level is a necessary part of planning, beginning with the Sprint can be critical to proving a concept or testing an assumption before investing too much in the planning process. Remember that decisions based on feedback are more reliable than those based on forecasts and speculation. As well, failing fast is as important as succeeding fast! Nothing can chew up a budget quicker than running off in the wrong direction.

Sprint to roadmap. Roadmap to Sprint. It’s often a round-trip!

In my next blog post, we’ll take a look at the breakdown of requirements at each level of planning.