The first of six (6) topics in the Iterative Implementation Approach - Reference covers the first set of Implementation Tasks. Those tasks execute the Analysis & Design aspects of Solution Delivery.
Participants who are unfamilair with an iterative approach to Transformation or Solution Delivery, as well as those who may be more familiar with a Waterfall approach, are often unsure of what is to happen and when. And while many folks may have some familiarity with terms like Stories & Sprints, unfortunatly too many think those are the extent of "Agile".
In fact, those with that belief are - in most cases - only looking at the last of the four Implementation Tasks (IT4): Story Build. This page on Analysis & Design and the followig page on Build, Test & Deploy seek to provide a broader perspective of the work involved with incremental Transformation and Solution Delivery.
Implementation Tasks 1 and 2 = Solution Analysis & Design (A&D)
Too many organizations make the mistake of jumping straight to Stories & Sprints believing this to be "Agile". It's on the path, but it's only a small portion of what's needed. Only focusing on Stories & Sprints is like having a team of brick layers show up to build you a house and, without any plans or framing done, to begin laying bricks in 2-week increments. You will get results; just not the ones you were expecting.
Regardless of whether a Waterfall or Iterative approach is being used, there is work to be done before any build-related activites get under way. There is still a need to:
- Gather requirements (called Acceptance Criteria);
- Design within the Solution framework; and
- Capture, and gain approval of, the functional and technical specifications of the desired Solution.
These pre-build efforts are referred to a Analysis & Design. The difference between a Waterfall approach and an Iterative approach isn't that Iterative foregoes Analysis & Design (as some believe). Rather it's that in an Iterative approach only a portion of the overall Solution is tackled at a time, After one portion is done, the next portion begins. And so on until the entire Solution is complete. Each portion is comprised of one or more increments of Business Value, with each increment referred to as a "Feature" of the Solution. Each portion is referred to as a "Release" within the overall Solution.
Analysis & Design defines the solution using two key, related tasks – IT1: Feature Planning and IT2: Story Analysis. IT1: Feature Planning is a prerequisite for subsequent IT2: Story Analysis.
The Big Picture
Context
To provide some context as to where are we in the Bigger Picture, Level 2 Planning should be concluded, which means:
- The Solution Roadmap has been updated.
In other words, some amount of Features have been identified and prioritized. However, any such Features are probably not well defined.
The objective now is to complete refinement of prioritized Features (primarily) and their related Stories (secondarily) to make a sufficient quantity of both “Ready”. This will ensure that subsequent delivery work is effective and efficient. To do so, A&D focuses on actions which appear in the left column of the Implementation Tasks diagram below.
What is a "sufficient quantity" of "Ready" Features and Stories? A good guideline is to have:
- 2+ Releases worth of "Ready" Features; as well as
- 2+ Sprints worth of "Ready" Stories.
How much that actually translates to will depend upon each Team's capabilities and should vary (increase) over time as the Team becomes more productive. It will also depend upon whether the Solution has a Monthly- , Bi-Monthly- or Quarterly-Release schedule. Longer Release windows allow for more, and for larger, Features to be made "Ready". Regardless of the number of Sprints or the productivity of a Team, achieving at least 2+ Releases of "Ready" Features is considered to be a "Healthy Backlog" of Features, and 2+ Sprints of "Ready" Stories is considered to be a "Healthy Backlog" of Stories.
It is important to recognize Analysis & Deisgn does not run on a Sprint or Release cadence. Activities involved in Analysis & Design have a higher priority than those involved with Build, Test & Deploy. "Ready" items are required inputs for any build; if they're not available, then build tasks suffer. Whatever time is needed to achieve and maintain a "Healthy Backlog" is the time first used. Remaining time each week can be devoted to build activities which occur within Sprints, The implication of this is that when starting off, all time will be devoted to only Analysis & Design activities. Once a "Healthy Backlog" is achieved, then some time can be devoted to Sprint activities. Over time a balance will form whereby some time each week is devoted to A&D, and the remaining time to BTD. The end of solution delivery occurs when there is no further Features prioritized for delivery or funding is removed.
Left-side Implementation Tasks
During A&D both Features and their related Stories are initially identified. These are added to the Solution Backlog and the prioritized for work.
The highest priority Features are targeted (but not officially selected) for some upcoming Release and worked. That is, they are refined, or groomed, until "Ready".
Only “Ready” Features can be selected during upcoming Release Planning Events and added to a Release Backlog.
Stories need not be “Ready” to be added to the Release Backlog; but only “Ready” Stories can be selected during subsequent Sprint Planning Events and added to a Sprint Backlog.
Refining Features and Stories to “Ready” is an ongoing effort, as long as more Solution changes are desired.
Solution Type Variations
The following topics on IT1: Feature Planning and IT2: Story Analysis are generally the same for all Solution Types - Products, Systems and Services. There is no need for any variation in the descriptions because a Solution is of one type or another. However, some Solution Types will have opportunities which are not available to others. These opportunities are explained at the end of each description.
IT1: Feature Planning - Begins with Business-level Requirements & Design
Feature Planning is what occurs before the Release Planning Event. The work related to Feature Planning is managed using a Kanban board in the Work Management System (WMS) titled “Feature Planning Board”. This board tracks Features as they progress, or regress, through five (5) states:
- State 1: Manage Backlog – This simply means a potential Feature has been identified. Identifying MVP Business Value typically occurs during Inception, as a split of an earlier, larger Feature, or as a result of a Solution Change Request (SCR). The Feature is merely added to the Solution Backlog with a minmal amount of information.
- State 2: Manage Solution Roadmap – This is the first prioritization of future-state Features. Segmenting the overall Solution into delivery of manageable Business Value increments occurs during Level 2 Planning. All Features are force-ranked in the Solution Backlog. Those near the top are targeted for a pending Release. Targeted Features appear on the Solution Roadmap.
- State 3: Feature Analysis & Design – This is when the Feature is activly being refined, or groomed. The desired future-state MVP is captured from the Customer’s perspective by defining Benefits and Acceptance Criteria, estimating level of effort, and identifying related Stories.
- State 4: Feature Review – During this state the MVP definition for a Feature is validated. Reviewing seeks to validate that what has been designed will, indeed, support the anticipated Business Value.
- State 5: Manage “Ready” Features – The Feature is now fully defined. It ahs been approved by the Customer, and is now available for selection during a Release Planning Event.
The table below describes the States a Feature may be in during the Analysis & Design portion of its lifecycle. These States appear on the Feature Planning Board which is used within the Work Management System (WMS) to manage the progress (or regress) of each Feature from the Backlog through to "Ready".
| Backlog | On Roadmap | In Analysis | Review | "Ready" |
|---|---|---|---|---|
| Feature identified during Inception or added via PCR. | Feature prioritized for an upcoming Release. | Feature is being refined (i.e., design & requirements defined, effort estimated) | Business Sign Off (approval) of Feature’s design and requirements. | Sign Off received. Feature is now available for selection in a Release Planning Event. |
| While here, Feature only needs Title, Benefits & preliminary Estimate to be a placeholder for some future Business Value. | It may be the next, after-next, or some subsequent Release, but is expected to be delivered in the next 6 – 12 mos. (2 – 4 Releases) | Feature’s priority shows when it’s ‘next in line’. Features with higher priority should already be in ‘Review’ or “Ready” state. | This is the 1st of 6 opportunities for the Business to ‘Reject’ the item and to send it back for additional / better work. | Feature will remain in this state until it is selected for work in an upcoming Release. |
| If work scoped as a Feature cannot be completed during a single Release, then it is too big, and must be deconstructed into two (or more) smaller Features. | ||||
Solution Type Variations
- Products: The description above applies to Product Soutions. What's described is what should be followed.
- Systems: Many System Solutions (e.g., infrastructure provisioning) can make repeated use of standardized Features and related Stories (e.g., to provision a Linux Server; or setup a Cloud Service). Where possible, leverage prior work by simply cloning a prior Feature / Story sets, updating as appropriate, and running them through the series of states as decribed.
- Services: Service Solutions also follow the steps described.
IT2: Story Analysis - Drive to Application-, Technology- or Service-level Functional & Technical Specs
Story Analysis is what occurs before the Sprint Planning Event. The work related to Story Analysis is managed using a Kanban board in the Work Management System (WMS) titled “Story Analysis Board”. The board tracks Stories as they progress, or regress, through four (4) states:
- State 1: Manage Backlog – This simply means a potential Story has been identifed. Each Story identifies MVP application. technology, or service functionality to enable and deliver a the parent Feature’s overall Business Value, or some portion thereof (via Inception or Feature Planning).
- State 2: Story Analysis & Design – This is when the Story is being refined, or groomed. Establishing the desired end-state from the Solution’s perspective by defining Roles, functionality, and Acceptance Criteria. As well as estimating level of effort to enable a “Ready” Feature, or some portion thereof.
- State 3: Story Review – This is when the proposed design is validated. Reviewing and validating the functional and technical specifications of the proposed solution and how they are expected to support the Feature’s overall design
- State 4: Manage “Ready” Stories – Story is now fully defined, approved by the Team, and available for selection during a Sprint Planning Event.
The table below describes the States a Story may be in during the Analysis & Design portion of its lifecycle. These States appear on the Story Analysis Board which is used within the Work Management System (WMS) to manage the progress (or regress) of each Story from the Backlog through to "Ready".
| Backlog | In Analysis | Review | “Ready” |
|---|---|---|---|
| Story identified during Inception or added as part of Feature refinement. | Story is being refined (i.e., requirements defined, work estimated) | Sign-Off of Story’s Acceptance Criteria, Points, etc, by Business, PO, Developer(s), Tester(s), etc. (i.e., approval) | Sign Off received. Story is now available for selection in a Sprint Planning Event. |
| While here, it need only have a Title / Summary to be a placeholder for some future Business Value. | Story is aligned to a Feature on the Roadmap and prioritized for an upcoming Sprint. | This is the 2nd of 6 opportunities for the Business to ‘Reject’ the item, and send it back for additional / better work. | Story remains in this state until selected for work in an upcoming Sprint. Any change to Story regresses it to ‘In Analysis’. |
| If work scoped as a Story cannot be completed during a single Sprint, then it is too big, and must be deconstructed into two (or more) smaller Stories. | |||
Solution Type Variations
- Products: The description above applies to Product Soutions. Follow the steps described.
- Systems: Many System Solutions can make repeated use of standardized Stories (e.g., to install an OS or App; configure a virtual network). Where possible, leverage prior work by simply cloning prior Stories, updating as appropriate, and running them through the series of states as decribed.
- Services: Service Solutions also follow the steps described.
Next up is an introduction to the second half of iterative delivery execution, Build, Test & Deploy.