The Scrum Lifecycles: Construction, Project, and Solution

Scrum teams inherently address far more than just construction in their overall way of working (WoW). This article explores the following topics pertaining to the Scrum lifecycle:

The Scrum construction lifecycle
The Scrum project lifecycle
The Scrum solution lifecycle
Why look beyond the Scrum lifecycle?
The Scrum lifecycle in context

1. The Scrum Construction Lifecycle

Figure 1 depicts the Scrum construction lifecycle. The lifecycle shows how agilists treat requirements like a prioritized stack, pulling just enough work off the stack for the current iteration (in Scrum sprints are often 2 weeks long, although this can vary). At the end of the sprint the system is demoed to the stakeholders to verify that the work that the team promised to do at the beginning of the iteration was in fact accomplished. If the sprint is successful, then the solution may be optionally deployed (not shown), or work may continue on with the start of new sprint. If the team is struggling the initiative may need to pivot or even be cancelled.

Figure 1. The Scrum construction lifecycle (click to enlarge).

2. The Scrum Project Lifecycle

The Scrum construction lifecycle of Figure 1, although attractive, proves to be clearly insufficient in practice. Where does the product backlog come from? Does it get beamed down from the Starship Enterprise? Of course not, it’s actually the result of initial requirements envisioning early in the initiative. You don’t only implement requirements during a sprint, you also fix defects, go on training, support other teams (perhaps as reviewers of their work), and so on. So you really need to expand the product backlog into a full work backlog (or just backlog for short). You also deploy your system into production, often a complex endeavor although one that is hopefully fully automated.

Figure 2 depicts an agile, Scrum-based project lifecycle. As you can see this lifecycle extends the Scrum Construction lifecycle of Figure 1. It adds an Ideation/Sprint 0 phase as well as a Deploy phase. Phases? Do agile lifecyles have phases? Yes!

Figure 2. The agile project lifecycle (click to enlarge).

The three phases of the Scrum-based agile project lifecycle are:

Ideation/Sprint 0. During this phase the vision is identified for what your team is tasked to accomplish. This may require significant work with your stakeholders to do so, including initial requirements envisioning, initial architecture envisioning, initial release planning, putting together the team, obtaining funding, and other fundamental initiation activities. Note that this phase is also referred to as inception, iteration 0, warm up, or initation.
Construction. This is where the team incrementally produces value for their stakeholders during short timeboxes called sprints. Note that this phase is also referred to as development, build, or simply sprints.
Deploy. This is where the team releases the solution that they have produced to their stakeholders. Ideally this work is fully automated using common DevOps practices such as automated regression testing, continuous integration (CI), and continuous deployment (CD). Note that this phase is also referred to as transition, deployment, release, or hardening sprint

3. The Scrum Solution Lifecycle

A more comprehensive depiction of the lifecycle is captured in Figure 3, overviewing the full Scrum-based, agile solution lifecycle.

Figure 3. A detailed agile SDLC (click to enlarge).

This lifecycle is comprised of six phases:

Concept. This is the period where the original concept for your initiative is identified, prioritized, and initially funded (at least for the next phase). Note that this phase is also referred to as strategy or portfolio strategy.
Ideation/Sprint 0. During this phase the vision is identified for what your team is tasked to accomplish. This may require significant work with your stakeholders to do so, including initial requirements envisioning, initial architecture envisioning,
initial release planning, putting together the team, obtaining funding, and other fundamental initiation activities. Note that this phase is also referred to as inception, iteration 0, warm up, or initation.
Construction. This is where the team incrementally produces value for their stakeholders during short timeboxes called sprints. Note that this phase is also referred to as development, build, or simply sprints.
Deploy. This is where the team releases the solution that they have produced to their stakeholders. Ideally this work is fully automated using common DevOps practices such as automated regression testing, continuous integration (CI), and continuous deployment (CD). Note that this phase is also referred to as transition, deployment, release, or hardening sprint
Production. This is the period of time where your solution is run and supported with your customers. For an existing solution (product or service) this will often occur in parallel to construction of an update to the solution. Note that this phase is also referred to as operations or business operations.
Retirement. This is where a solution is removed permanently from production. This may be because you have replaced the existing solution with a completely new offering or because you have simply decided to no longer support the solution for your customers. Note that this phase is also referred to as decommissioning.

4. Why Look Beyond the Scrum Construction Lifecycle?

There are very good reasons to go beyond the classic Scrum construction lifeycle of Figure 1:

Solution development is complicated. Although it’s comforting to think that development is as simple as Figure 1 makes it out to be, the fact is that we know that it’s not. If you adopt a development process that doesn’t actually address the full development cycle then you’ve adopted little more than consultantware in the end. My experience is that you need to go beyond the construction lifecycle of Figure 1 to the full SDLC of Figure 3 (ok, Retirement may not be all that critical) if you’re to be successful.
There’s more to IT than development. To be successful at IT you must take a multi-system, multi-lifecycle stage view.
The reality is that organizations have many potential initiatives in the concept stage, many in development, and many in production. There may even be one or two retirment initiatives underway

5. The Scrum Lifecycle in Context

The following table puts the Scrum lifecycle into context. No lifecycle is suited for all situations, including this one.

Advantages	TBD
Disadvantages	TBD
When to Use It	This lifecycle is well suited for teams that deal with an ongoing stream of work requests that need to be addressed continuously (not batched up). This includes teams evolving existing software applications, existing data warehouse (DW)/business intelligence (BI) solutions, help desk teams supporting customers, or internal service teams.