Designing an Agile Sprint Process

A mature software development lifecycle (SDLC) should be used to manage a document management system (DMS) development project that require significant software development. Particular application development projects require particular SDLC frameworks; each application development project should be managed using the appropriate SDLC for that project. At a very basic level, there are at least two types of software development frameworks that can be used: Waterfall and Agile. In the simplest terms, the Waterfall methodology produces all of the end products of a system at the end of the project’s single software development cycle. As an alternative, the Agile methodology produces end products in a sequential series of short, repeatable software development cycles. The emphasis in the Agile methodology is an iterative approach to software development in which the steps of the Waterfall SDLC are compressed into shorter timelines and are repeated at multiple times throughout the year. In some cases, an Agile-based SDLC instance for end-user features and functionality can be completed in eight (8) weeks. There is also a hybrid of these two types of software development cycles in which the foundation of a system is developed using the Waterfall approach while additional features for the system are developed using the Agile approach.

Each SDLC methdology—Waterfall and Agile—are often used in building a DMS. This hybrid approach comprises two streams of concurrent, related development: the End User Functionality Build Cycle and the Application Infrastructure Development Cycle. The End User Functionality Build Cycle focuses on the development of end-user features particularly within end-user interfaces (UIs) while the Application Infrastructure Build Cycle focuses on the development of an application’s infrastructure—any part of the application’s functionality that the typical end user will not directly interact with. Once the separate builds are developed in a sandbox environment and in a development (DEV) environment, the two builds can merge into one build and proceed through the remaining SDLC as one build to be tested and ultimately deployed and released at the end of the Agile lifecycle or sometimes at the end of a quarter in the case of quarterly releases.

For faster approach, and SDLC build can be tested in testing (TST) environment and a staging (STG) environment and then deployed and released into a production (PRD) environment at the end of its particular build cycle. For a more conservative approach, all SDLC builds that are successfully tested within a particular quarter can be set aside until the end of that particular quarter. At the end of that particular quarter, all of the successful builds can be funneled into the Deploy and Release Sprint, which occurs during the last two (2) weeks of each quarter. During the Deploy and Release Sprint, the successful builds are deployed to PRD and released. This quarterly Release and Deployment Sprint has a two (2) week timeframe. If the Release and Deployment Sprint occurs quarterly, end-user functionality builds and application infrastructure builds are only deployed and released into PRD four times per year.

Each End User Functionality Build Cycle contains segments called sprints. The following are those sprints:

• Requirements and Design Sprint

• Development Sprint

• Testing Sprint

• Deploy and Release Sprint

The following is a sample Agile sprint schedule that can be used. This particular sprint schedule lasts for eight (8) weeks.

Sample Agile Sprint Schedule:

Requirements and Design Sprint:

Build x - Requirements Sprint (begins on a Tuesday; lasts 10 business days)

Build x - Requirements Submitted (last day of the Requirements Sprint at 4:00)

Development Sprint:

Build x - Development Sprint (begins on a Tuesday; lasts 10 business days)

Build x - Mid-Sprint Demo (Tuesday after beginning of development sprint at 1:00)

Build x - Push-to-TST CM Ticket Submitted (second Wednesday after beginning of development sprint at 3:00)

Build x - Push-to-TST CM Ticket Approved (last day of development sprint at 11:00)

Build x - Snapshots and Backup of TST (last day of development sprint at 1:00)

Build x - Push to TST (last day of development sprint at 3:00)

Testing Sprint:

Build x - Testing Sprint (begins on a Tuesday; lasts 10 business days)

Build x - Test Results Submitted (last day of testing sprint)

Deploy and Release Sprint:

Build x - Release Sprint (begins on a Tuesday; last 3 business days)

Build x - Push-to-PRD CM Ticket Submitted (Tuesday, first day of testing sprint at 11:00)

Build x - Push-to-PRD CM Ticket Approved (last day of testing sprint at 3:00)

Build x - Snapshots and Backup of PRD (last day of testing sprint at 5:00)

Build x - Push to PRD (last day of testing sprint at 7:00)

Build x - Push to PRD Validation (last day of testing sprint at 9:00)

Build x - Go/No Go in PRD (last day of testing sprint at 11:00)

Build x Release:

Build x - Distribute Release Notes

Build x - Publish New Features Announcement

Build x - Demo of New Features

To produce new features and functionality more than once every eight (8) weeks, the vendor could use a sprint schedule that stacks build cycles upon one another that are slightly staggered. For example, once the requirements sprint cycle for Build 1 is completed, the requirements sprint cycle for Build 2 begins. This stacked and staggered build-cycle schedule can then produce features and functionality every two (2) weeks instead of every eight (8) weeks. The exception to this is if an organization and a vendor decide to release multiple builds together in a more conservative quarterly approach.