Agile Gating & Artifact Approach

Generally speaking, any LAUNCH LEGENDS project that is implementing a new technology, a new integration, optional enhancements, or is allocating > $10K toward their solution is expected to attend project gates to minimize risk and ensure quality is delivered.

In order to ensure that gating continues to be an effective risk control and does not become a blocker for Agile teams trying to develop rapidly, a separate gating process for Agile projects has been developed. Since Agile Sprints themselves contain Design, Build, and Test activities, Agile projects will not go through the same Requirements, Design, and Build & Test Gates that make sense for waterfall. Instead, Agile projects will only deal with 2 gates which touch and allow project teams to confirm they have done the work necessary to prove 2 key concepts to reduce project risk: that they are “Ready to Sprint”, and later that they are “Ready to Deploy”.

The table below outlines the Gating approach for Agile projects, as well as the expected Artifacts a team should be able to have produced by that point in an Agile process. How these artifacts should be approached is outlined in the methods themselves.

Gate

Description

Expected Artifacts for Agile Projects

Planning Gate

(All Projects)

Attended by ALL projects (Agile included)

PURPOSE: To ensure that the business need is clearly defined and understood, the project has completed a Solution Path Filter, and understands what they want to create for the solution

WHEN: Prior to Agile Planning Sprint Start

Phase 1

Project Entry into PPM tools
Solution Path Filter (SPF)
Project Charter (from SPF)
High Level Scope & Business Objectives (i.e. Agile Vision & Themes)

Phase 2

High Level Product Requirements
High Level Business Requirements (i.e. Agile Epics, prioritized)
High Level Technical requirements (i.e. Agile Epics, prioritized)
Identified Actors/User Types

Backlog Readiness Gate

(SPF Risk >=80)

(i.e. “Ready to Sprint”)

Attended only by High-Risk Agile projects, more specifically those with a risk score of 80+ as defined in the SPF.

PURPOSE: To ensure that the project has done the necessary activities to ensure Agile development can proceed in a smooth fashion and that the solution is defined clearly enough to begin executing Sprints

WHEN: The Backlog Readiness gate review should be scheduled during Sprint Zero after the Planning Sprint is completed

Phase 1

Solution Roadmap (Releases, Milestones, Sprints)

Phase 2

Solution Design (High-Level)
Testing Strategy (Within, Outside Sprints)
Solution Backlog (User Stories, Acceptance Criteria)

Sprint Release Gate

(SPF Risk >=50)

(i.e. “Ready to Deploy”)

Attended only by High- and Medium-Risk Agile projects, more specifically those with a risk score of 50+ as defined in the SPF.

PURPOSE: To ensure that the project has executed its Sprints in an effective fashion and has taken the necessary steps to ensure the solution is Production-ready

WHEN: After enough Sprints so that the Solution is deemed by the Product Owner to be “ready” for Production. This will depend on the specific project as to whether it is a few or many sprints, etc.

Phase 1

Release Backlog (i.e. stories ready for deployment
Test Results (Within, outside Sprints, including Security Scan)
Sprint Closure Memos (Product Owner Acceptances)

Go/No Go Checklist

UPDATED ARTIFACTS (if changed during Sprints):

Solution Design Updates