The first of four (4) tasks in the ITM's Iterative Implementation Approach. These tasks drive and manage ongoing Solution Delivery.
IT 1 - Define What the Customer Wants
PL3.1 – Features into Value Increments (MVP) described the Iterative Planning task in which Features that appear on the Solution Roadmap are chosen to be refined (a.k.a., groomed). IT1: Feature Planning is the corresponding task which manages that activity.
IT1: Feature Planning begins with an outline of a Feature - often no more than a title, brief description, and perhaps an early list of anticipated benefits - and ends once the Feature is "Ready" for subsequent delivery activities. Feature refinement, or grooming, is managed in the Work Management System (WMS) through the use of a Feature Planning Board.
Feature Planning Board
In the graphic the five (5) columns to the left represent the States that a Feature may have while it is being refined. The arrows represent the permissible transitions from one State to another per the configured Feature Workflow.
A Feature Planning Board is a Kanban board. Any Solution may have multiple Feature Analysis Boards, allowing for varying ways to highlight relevant Feature attributes (e.g., to highlight Team, or Priority, or Assignee).
However, a better way is to have a single board and to use Quick Filters to highlight desired perspectives (assigned Team, Theme, parent Epic, etc.). Regardless of how many boards are used, understand that the Features displayed all boards reside in a single, underlying Solution Backlog. Multiple boards simply allow for viewing that single backlog in multiple ways to suit multiple audiences.
Each of the Feature Planning Boards may use Column Labels tailored to suite the board's target audience (e.g., Feature Refinement Manager, CCB, Project Status Reporting). However, regardless of the labels used on each column, there are specific State values associated with each column. It is these State values that determine which Feature appears in which column.
These State values, along with the WMS Workflow, also determine the State to which a Feature can be changed based upon its existing State (i.e., workflow rules). Constraining the flow of work makes it easire to manage and reduces the chance of important work getting lost in the shuffle.
Measuring Refinement Progress by Feature State
The graphic above depicts the five (5) States that a Feature being refined may have. The following describe each State and what it means when a Feature is assigned to that State.
| Backlog | On Roadmap | In Analysis | Review | "Ready" |
|---|---|---|---|---|
| Feature identified during Inception or added via Program Change Request (PCR). | Feature prioritized for an upcoming Release. | Feature is being refined (i.e., design & requirements defined) | Business Sign Off of Feature’s design and requirements. | Sign Off received. Feature is now available for selection in a Release Planning Event. |
| While here, it need only have a Title / Benefits and 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” states. | This is the first of six (1 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. |
| Step 1 | Step 2 | Step 3 | Step 4 | Step 5 |
IT1 Artifacts - Inputs
Solution Strategy & Architecture
During Portfolio Management, or prior to the start of Phase Inception, a series of artifacts are created to help define, and possibly to help select, the given Solution. Initial, high-level Solution Strategy materials are tailored into Solution Approach materails to guide overall Solution design and development. Along with related Solution Diagrams & Component descriptions, the Solution Strategy & Architecture artifacts provide a framework a guidelines to follow for each subject area listed below. Apply these materials as they relate to any given Feature.
Business Process Definition(s)
For Product Solutions many Features will represent some business process or portion thereof. The definition of such business process is something which needs to be completed before defining any related Business Features. While the Features of a Solution can be managed in an iterative fashion, defining related business processes cannot.
Each business process that the Solution is to support must be defined (documented, reviewed and approved) before the enabling Features can be defined. That said, if a Solution will support multiple business processes, not all processes need to be defined before any Feature is defined. Only those process which are in-scope for the current Phase need be defined; those that will be addressed in later Phases can be deferred until such time as they can be completed prior to the Phase in which they will be worked begins.
At minimum, the process to which a Feature relates must be defined before that Feature can be properly refined. For more information see Business Processes Definitions.
Outputs from PL1 - Vision and PL2 - Roadmap
Outputs from previously completed Solution Planning efforts are inputs into Feature Planning.
The Solution Roadmap provides prioritization for the sequence in which Features should be refined. Note that several Features should be going through Feature Planning at all times. This allows a Team to shift focus from one to another when impediments are encountered or scheduling conflicts impair progress on any given Feature. Impediments may includes waiting upon decisions to be made, or for availability and access to a key resource. Teams should never become idle in such situations, they should just move on to the next available Feature to refine.
Apply the results of earlier efforts in the current Feature Planning task, and ensure that individual Features going through this task retain their alignments with these materals.
Prior Solution Work / Legacy Artifacts
As the Solution advances over time it is very likely that some Features will build upon work done in earlier Features. There is no need to repeat or replicate that which was done for prior Features. Simply refer to them and their content as needed.
Similarly, there may be work related to a legacy system (designs, specifications, etc.) which still have relevancy to the current Solution. Again, no need to reinvent any wheels, simply capture and reference any prior knowledge capital.
IT1 Artifacts - Outputs
"Ready" Features
As each Feature progresses through the IT1: Feature Planning task it continues to evolve, The objective is to fully define the desired solution design for each increment of Business Value (i.e., for each Feature). For additional information on what information is captured to define the design, refer to Implementation Task 1 of 4 - Feature Planning.
New Stories
Defining each Feature includes identifying increments of functionality needed to achieve a Feature's Business Value. In other words, what changes will achieve the Feature's objective? Moreover, how will those changes be delivered?
In this case, change occurs via functional increments. That is, things like input pages, data processes, and reports. Each increment is a change managed using a Story. Generally, anyone may add a Story to the Solution Backlog at any time. Even so, Teams should add Stories when analyzing the Feature and determining MVP. Refer to IT1 - Step 3 of 5: Feature Analysis & Design for more information. Additionally, refer to Implementation Task 2 of 4 - Story Analysis for subsequent work on each Story.