The second of six (6) topics in the Iterative Implementation Approach - Reference covers the second set of Implementation Tasks. Those tasks execute the Build, Test & Deploy aspects of Solution Delivery.
People unfamilair with an iterative approach to Transformation and/or Solution Delivery are often unsure of what is to happen and when. Similarly, those who may be more familiar with a Waterfall approach may misunderstand how actions conducted in that method change when applying an iterative approach.
The prior page on Analysis & Design, and this page on Build, Test & Deploy, seek to provide a broader perspective of the work involved with incremental Transformaiton and Solution Delivery.
Implementation Tasks 3 and 4 = Solution Build, Test & Deploy (BTD)
Having completed the activities associated with Analysis & Design attention now shifts to turning the approved ideas, designs and specifications into tangible deliverables. In other words, to build the Solution.
Build, Test & Deploy creates the Solution using two key, related tasks - IT3: Feature Release and IT4: Story Build. Some parts of IT3: Feature Release occur prior to IT4: Story Build. Other parts occur following Story Build.
The reason for this is that work is occurring on two levels. At the higher, Feature-level, increments of Business Value are prioritized for delivery to the Customer. At the lower, Story-level, increments of Functionality are prioritized for development by the Delivery Team to enable each corresponding Feature.
The Big Picture
Context
To provide some context as to where are we in the Bigger Picture, Level 3 Planning should be concluded, which means:
- A Release Planning Event has occurred.
- “Ready” Features were selected for delivery in the Release.
- Those Features, and any related Stories known at the time (whether "Ready" or not), have been added to a Release Backlog.
- Each Release of the given Solution involves some fixed number of Sprints (e.g., 6 Sprints for a Quarterly Release; or 4 Sprints for a Bi-Monthly Release, or 2 Sprints for a Monthly Release).
Now, the objective is to complete all Stories so their parent Features are "Done" by the end of the Release's Last Sprint. To do so, BTD focuses on activities that appear on the right column of the Implementation Tasks diagram below.
Right-side Implementation Tasks
The selected Features, and their related Stories, are worked during the Sprints within the Build Release.
Following the a Release's Last Sprint, those Features that are ‘Accepted’ by the Solution Owner / Customer will be added to a Candidate Release and then progress toward Certification Testing and/or UAT as appropriate for the Solution Type.
Features which pass Certification Testing and UAT progress toward Production deployment as increments to the Production Release.
Solution Type Variations
The following topics on IT3: Feature Release and IT4: Story Build vary depending upon the Solution Type. Products are the most complex solutions and are the basis for the descriptions below. Systems and Services are simplier solutions, each use varying subsets of what is described below. The simplified subsets are explained at the end of each description.
IT3: Feature Release - Advance the Solution by Delivering Increments of Business Value
Feature Release is what occurs after the Release Planning Event, and is managed using a Kanban board in the Work Management System (WMS) titled “Feature Release Board”. The board tracks Features as they progress, or regress, through eight (8) states:
- State 1: Feature “Ready” – Features available for selection during a Release Planning Event. This is the same as the final state of IT1: Feature Planning.
- State 2: Feature in Build Release – “Ready” Features selected for delivery during the Release Planning Event are added to the backlog of the next Build Release. Stories & Bugs related to these Features should be prioritized for work during Release Sprints.
- States 3 – 5: Feature in Candidate Release – After the final Sprint within the Build Release, "Done" Features are added to the next Candidate Release and progress through three states related to Certification Testing and UAT.
- States 6 – 8: Feature in Production Release – When the validated and accepted Features from the Candidate Release are added to the next Production Release, they are deployed to Production where each may be either Inactive (unusable / unavailable ) or Active (usable / available). Inactive Features from prior Releases may also be activated.
The table below shows the States a Feature may be in during the Build, Test & Deploy portion of its lifecycle. These States appear on the Feature Release Board which is used within the Work Management System (WMS) to manage the progress (or regress) of each Feature from being "Ready" through to being "Done", then on to Cerfification Testing (if appropriate), and finally toward becomming Active in Production. The bottom row shows which concurrent Release a Feature belongs to while in a given State. See the following section for additional information on the Environments in which related Features may be found.
| Ready | Build | Cert Testing | Ready for UAT | UAT Accepted | Move to Production | Inactive in Prod | Active in Prod |
|---|---|---|---|---|---|---|---|
| Feature available to work in a Build Release | Features Selected during Release Planning Event | Feature undergoing Certification Testing (System, NFR, Performance) | Final Business review | Business approved Feature for Production | Feature targeted for promotion to Prod | Feature deployed to Prod | Feature deployed to Prod |
| Release Planning Events can only select from “Ready” Features | In Release Backlog, to be delivered in ‘Build’ Release | 5th of 6 opportunity for to ‘Reject’ the item, and send it back for change | 6th and final opportunity to ‘Reject’ item and send back for change | Feature now in the hands of DevSecOps | Feature is in Prod, but Toggled Off (i.e., not in use) | Feature is in Prod and Toggled On | |
| Build Release | Candidate Release | Production Release | |||||
Solution Type Variations
- Products: The description above applies to Product Soutions. What's described is what should be followed.
- Systems: System Solutions typically do not include a Candidate Release. As such, Build Release Features which are not subject to Certification or UAT testing may progress directly from "Done" to 'Move to Production'
- Services: Build Release activities may apply to Service Solutions. However, neither the Candidate Release nor Production Release related activites are typically tracked within the WMS. Each is the responsibility of the Service Provider.
IT4: Story Build - Deliver Small Increments of Application-, Technology- or Service-Functionality
Story Build is what occurs after to the Sprint Planning Event, and is managed using a Scrum board in the Work Management System (WMS). The board tracks Stories as they progress, or regress, through the eight (8) states shown below.
- State 1: To Do – "Ready" Stories selected during a Sprint Planning Event. This is not the same as the final state of IT2: Story Analysis.
- State 2: Work in Progress – Development or configuration along with Unit and Functional (FNC) Testing of new functionality.
- State 3: Technical Review – The Technical Lead (or delegate) reviews of developed solution to ensure standards are met.
- State 4: Functional Review (Desk Check) – Functional review, by Solution Owner and SMEs (ideally), of the developed solution. This is the last opportunity for anyone to request minor changes.
- States 5 – 6: Integration Testing – Promotion of the developed solution from DEV1 to TST1 and the corresponding transactional Integration (INT) testing efforts using both positive and negative tests.
- State 7: Ready for Sign-Off – When the developed solution and corresponding FNC & INT Test Results are presented (Demonstrated) to the Customer for their Acceptance.
- State 8: “Done” – No further work is expected. If any more work is expected, the Story is not “Done”. Following the Release's Last Sprint, only if all Stories related to a Feature are "Done" can the parent Feature itself progress from the Build Release to the Candiddate Release.
The table below shows the States a Story may be in during the Build, Test & Deploy portion of its lifecycle. These States appear on the Story Build Board which is used within the Work Managment System (WMS) to manage the progress (or regress) of each Story from "Ready" through to "Done".
| To Do | Work in Progress | Code Review | Desk Check | Ready for Testing | In Testing | Ready for Sign-Off | “Done” |
|---|---|---|---|---|---|---|---|
| Story selected during a Sprint Planning Event | Product changed being made and Operating Procedures being created / updated | Technical Review, Dev / Config standards validation | Functional Review, PO / Bus review of new / changed functionality; Last chance for (minor) change | Business Approved functionality | Remaining Build-level tests (Integration - INT) | Functionality demo and corresponding Build Test results | Functionality ‘Accepted’ as-is by Business |
| In Sprint Backlog, to be delivered in current Sprint | Functionality being developed and tested (Functional - FNC) | Tech Lead (DevSecOps) review of new / changed solution components | 3rd of 6 opportunities for to send back for additional / better work. | No further component changes planned | Validate the delivered component(s) | 4th of 6 opportunities to ‘Reject’ item, and send it back for change. | Portion(s) of overall Feature complete |
Solution Type Variations
- Products: The description above applies to Product Soutions. Follow the steps described.
- Systems: Some states may not be applied in the same way for System Solutions. For example, standardized builds such as the provisioning a server, would typically not require the functional (i.e., Business) review of 'Desk Check' and 'Ready for Demo'. However, the implied validation to occur in each step should still be done, likely by a supervisor or peer of the individual who executed the work.
- Services: The steps described above will apply to most Service Solutions.
The Alignment of IT3: Feature Release and IT4: Story Build in the ITM
The figure at right shows the relationship between IT3: Feature Release and IT4: Story Build.
In a nutshell, as long as Stories remain in the Release Backlog that are not "Done", working those takes precedence over building any other Story that may be in the Solution Backlog. This helps to ensure that Features selected for delivery during the Build Release are actually completed and 'Accepted' in order that they may progress into the Candidate Release. Note that Sprints only apply to the Build Release.
A Candidate Release is time constrained to the same number of weeks as a Build Release. However, Certification Testing is not scheduled on a Sprint-by-Sprint basis, although any required Bug fixes are.
The Candidate Release is time constrained because if it takes longer to complete a Certification Testing & UAT cycle than it does to produce the next Build, then over time a backlog of uncertified Candiddates will accumulate. There are many reasons and implications as to why this is not desireable. Also, although Candidate-related work occurs in parallel with Build-related Sprint efforts of the following Release, Candidate-related work is not scheduled on a Sprint-by-Sprint basis becuase it is not structured nor estimated for such planning. Test Planning and execution must allow for trade-offs to ensure appropriate testing can be completed within the time constraint of a Build cycle.
In fact, whther Certification Testing is required, and the amount of time needed to allow for it, is perhaps the biggest driver in determining which Release Schedule (Monthly, Bi-Monthly or Quarterly) a Solution should use.
The Poduction Release is not time constrained at all. New Features (those which have achieved a 'Move to Production' state) or other changes to Production can occur as and when needed.
BTD Support Tools & Environments
Tools
Build, Test & Deploy builds upon the information gathered during Analysis & Design and managed within the Work Management System. Features & Stories in the WMS will be updated, and additional content will be added to the Test Management System.
Environments
The actions above often need to occur in one of several Environments. For additional information on what happens where, look to Code, Test & Work Progression.
Additional Information
See the following for more information on the Implementation Tasks related to Build, Test & Deploy.
For additional reference information:
For execution information:
Next up is a deeper dive into Implementation Task 1 (IT1): Feature Planning.