The fourth of four (4 of 4) tasks in the ITM's Solution Portfolio Approach manages the systematic identification, selection and definition of changes needed to fulfill a Customer Request for Change. Together, the four (4) tasks drive and manage ongoing Portfolio Management. These actions conclude Change Request Management. Thereafter, further work fulfilling the Request will transition on to Solution Delivery.
At this time, the parent Feature (Request) represents some feasible, potential change to the IT Portfolio. As a result, the TMO must now identify alternatives, produce resource estimates, select from available options, and otherwise prepare to implement desired change. Elaborate Stories represent individual artifacts, produced to provide a thorough, proper definition of any new Epic(s) and/or Solution(s).  In short, this work takes the Feature (Request) from "Ready" to "Done".
Portfolio Task 4 - Complete Solution Definition
Overview
At this point, Portfolio Task 4: Elaborate Stories manages the work to produce artifacts that complete portfolio Change Request Management. As the parent Feature (Request) progresses through PT3: Elaborate Feature, several steps add Elaborate Story sets to the Portfolio Backlog. Each contributes towards the identification, selection, and definition of potential portfolio change. In other words, to the creation of new Epic(s) and/or Solution(s).
To begin, TMO will identify potential options to fulfill the Request. For each option, a high-level assessment looks at appropriate software, hardware and architectural options, along with the costs and benefits of each. Costs and benefits look not only to acquisition, but also to implementation and ongoing operations. Afterwards, Level 1 Planning outlines out a recommended course of action. Altogether, these materials contribute towards the development of an initial Business Case.
If approved to proceed, the Request undergoes capacity planning and scheduling to identify needed resources, and their availability. If new Epic(s) alone cannot fulfill the Request, then participants make software, hardware and/or architectural selections for one or more new Solutions. At this time, select Vendors, complete purchase or licensing agreements, and engage 3rd Party implementation assistance. Correspondingly, architects will produce each Solution's initial Strategy & Architecture.
Additionally, if a new Epic or Solution supports business operations, then the TMO facilitates development of new Business Process Definitions for each process in-scope for the initial Solution Phase. At this point, participants drive the process definitions prepared earlier down to their next, and lowest, level of detail. That is, they will map desired business operations to out-of-the-box, delivered functionality. As a result, the scope and effort of work required to fulfill the Request will begin to come into focus.
Transition from Solution Definition to Solution Delivery
The materials produced prior to this point become inputs to Solution Inception. At that time, participants establish the tools and processes to support implementation. Additionally, they will create a "healthy" Solution Backlog, separate and distinct from the Portfolio Backlog. Moreover, participants will also produce the initial Level 2 Plans.
Afterwards, Portfolio Level and general Solution Level leadership conduct a final validation to ensure Solution Definition is complete, and that proposed changes will move the organization in right direction. Afterwards, TMO will transition further responsibility for fulfilling Request on to ongoing Solution Delivery. In effect, completing all Elaborate Stories concludes the TMO's involvement with Change Request Management.
The end of this task occurs once all Elaborate Stories relating to the parent Feature (Request) are "Done". At that point, the Feature itself completes its progression from "Ready" to "Done". The Work Management System (WMS) provides the tool to manage these definition actions, through use of the Elaborate Stories Board.
Elaborate Stories Board
In the graphic, the five (5) columns on the right represent the States that a Story may have during Elaborate. The arrows represent the permissible transitions from one State to another per the configured Portfolio Story Workflow.
Unlike other Portfolio Management boards, an Elaborate Stories Board is a Scrum board. Like other boards, the TMO may create multiple Story Build Boards to suit varying Change Request Management audiences. However, a better way is to have a single board and to use Quick Filters to highlight desired perspectives.
Regardless of how many boards are in use, understand that the Stories displayed all reside in a single underlying backlog. This is the Portfolio Backlog. Alternatively, recognize that some latter steps call for the addition of Solution-related Features and Stories to a Solution Backlog. Remember, the TMO uses the Portfolio Backlog to manage Requests for Change and the overall IT Portfolio. Solution Delivery groups use Solution Backlogs to manage individual Solutions.
Indeed, if using multiple Elaborate Story Boards, each may use Column Labels tailored to suit the board's target audience. However, regardless of the Label on each column, behind it there are specific State values associated with each column. In fact, it is these State values that determine which Stories appear in which column. Additionally, these State values, along with the WMS Workflow, also determine to what State a Story can change based upon its existing State.
Measuring Artifact Progress & Priority
To illustrate, the graphic above depicts the six (6) States that a Story may have during Elaborate. Seeing that, the following describes each State, and what it means when a Story contributing to Change Request Management is assigned to that State.
Artifact Progress
To begin, WMS Boards typically allow for two types of tags. The ITM refers to these as States and Labels. Each contributes differently to monitoring items as they progress through Change Request Management.
States
To explain, a State is a configuration within the WMS. As a result, the use of States often occurs behind the scenes. For instance, they are the values which WMS Workflow reference. Similarly, these values often appear in WMS Reporting. The reuse of States occurs often, across boards, as well as across Solutions. Hence, they may indicate different things, at different times, on different boards.
Labels
Alternatively, a Label is a name, or title, given to a column. That is, Labels provide a context, or other indication, for the contents of a column. Significantly, a column, and hence a Label, may have multiple States associated with it. Similarly, one can associate the same State with different Labels on different boards. In other words, consider a Label to be an explanation, or clarification, of the State(s) intended use, in the column, within the context of the given board.
| WMS Story State | Description |
|---|---|
State = To Do | Context: Unlike Solution Delivery, Change Request Management Stories previously made "Ready" during Intake & Ideate do not progress on to Elaborate. Instead, the TMO will add sets of new Elaborate Stories as the parent Feature (Request) progresses through Elaborate. Each new Elaborate Story set is added to the Portfolio Backlog. Moreover, their addition places them into the same Portfolio Release as the Feature (Request). Afterwards, the TMO selects a subset of Elaborate Stories into a Sprint during a Sprint Planning Event. Selected Stories begin on the Elaborate Story Board in the 'To Do' State. This State indicates that Stories which appear in this column represent the current Sprint Backlog. Moreover, it means participants must produce the artifact(s) to which the Story refers to move the parent Feature (Request) through Elaborate. Actions: While in this State, no additional work should be done on the Story. However, either the Scrum Master (if used) or the person to whom the parent Feature is assigned will prioritize Stories in this column by moving them up or down. Owner: If the TMO is using Scrum Masters, then assign all Stories selected during the Sprint Planning Event to the Scrum Master. Alternatively, assign them to the same individual who owns the parent Feature (Request). The initial Assignee will in turn re-assign each Story to an individual expected to produce the artifact to which the Story refers. |
State = In Progress | Context: When the individual or group to whom the Story is assigned (i.e., the Assignee) begins work on their next Elaborate Story they move the Story on the Elaborate Stories Board from 'To Do' to 'In Progress'. This State indicates that the Story is being actively worked. In other words, that the Assignee or other supporting participant(s) are in the process of producing the artifact the Elaborate Story identifies in support of Change Request Management. Actions: Assignees should always select the highest priority Story they can work on. Importantly, there is a limit to the number of Stories an Assignee can work on at any given time. In general, the limit is based on the resources who own it. Good management practices help individuals focus on completing a few (2 – 5) Elaborate Stories at any given time. It is bad management to assign anyone more than 5 Elaborate Stories at any given time. If an impediment is found which prevents progress on a Story, consider removing that Story from the current Sprint. Do not select the Story into another Sprint until the impediment is resolved. Otherwise, produce the artifact indicated by each Story. Owner: While in this state the Story is assigned to the TMO member, supporting Business Analyst or Technical Analyst, or Architect responsible for producing the corresponding artifact. |
State = Functional Review | Context: When the Assignee believes the work related to an Elaborate Story is complete they move the Story from 'In Progress' to 'Stakeholder Review' on the Elaborate Stories Board. In effect, the Story's State progresses from 'In Progress' to 'Functional Review'. This State indicates the related Change Request Management artifact is ready for stakeholder inspection. In other words, this is a final opportunity for stakeholders to affect the artifact before it is presented for final Review & Sign-off. This step did not exist for Ideate Stories. The reason it appears here is that Elaborate artifacts are more complex. Moreover, subsequent actions based on their content also have greater impact upon the organization. In fact, stakeholders should be consulted during the development of each artifact. However, this state is an opportunity to ensure the proper individuals provide required input before the artifact is complete. Actions: Each type of artifact has a different set of stakeholders. Ideally, each Story should identify key stakeholders whose input is desired. The Assignee (see below) becomes responsible for ensuring designated stakeholders receive the artifact. Further, they are also responsible for ensuring any feedback is addressed before the Story progresses on to the next State. Owner: After moving the Story into this State, the individual producing the artifact re-assigns the Story to either the Scrum Master, Solution Manager, or Project Manager, as appropriate for the organization. |
State = Ready for Sign Off | Context: Once stakeholder requested updates to the corresponding artifact are complete, the Assignee moves the Story from 'Stakeholder Review' to 'Ready for Sign-Off' on the Elaborate Stories Board. In effect, the Story's State progresses from 'Functional Review' to 'Ready for Sign-Off'. This State indicates the final version of the related artifact is available. Now, it is time for those accountable for each artifact, as well as the Solution Manager, Epic Owner(s) and Sponsor(s) to either accept each Change Request Management artifact 'As is', or to send it back for recommended changes. Actions: Indeed, the actions here are like those of the prior step. However, the audience is often different. If work is properly prioritized, most Elaborate Story sets build toward a larger Feature (Request). To best present each Story's work product, the TMO should present it in the context of its related Request. In other words, rather than present artifacts independently, each presentation should focus upon the Feature (Request). Completion of each artifact set may extend over several Sprints within a Release. As each completes, the impact upon the Feature (Request) becomes clearer. This continues until each artifact set, corresponding to each Elaborate Story set, is complete. Accordingly, as the number of related artifacts grows, key stakeholders will have ever more insight, understanding and confidence in the Solution's content. Like a 'Demo' in Solution Delivery, the completion of each Story set offers a good opportunity to present the artifacts together. Afterwards, with approval, the Feature (Request) itself may progress. Owner: The Assignee remains the same as the prior step. |
State = Done | Context: The Assignee moves each Elaborate Story accepted by key stakeholders from 'Ready for Sign Off' to 'Done' on the Elaborate Stories Board. This State indicates that work on the related artifact is complete. As the corresponding Feature (Request) progresses through PF3: Elaborate Feature (Request), these Stories remain in this State. In due time, once the Feature (Request) itself is "Done", they will be 'Closed'. Actions: Aside from moving the Story into this State, no other actions are expected at this point. Owner: The Story may retain its existing Assignee. Alternatively, an organization may remove the Assignee, or change it to a general, supervising Assignee. |
State – Closed | Context: While not depicted on the Elaborate Stories Board, there is a final State for Elaborate Stories. After a Feature (Request) transitions from Solution Definition to Solution Delivery, the State of all Stories (Ideate & Elaborate) associated with progresses from 'Done' to 'Closed'. As a result, this removes the Stories from the Portfolio Management boards. However, they remain accessible within the Portfolio Backlog. This is the final state the Elaborate Story may have. Actions: Aside from moving the Story into this State, no further actions are required. Owner: Some organizations prefer to leave the Assignee for historical purposes. Others remove the Assignee as no further work is anticipated. |
Artifact Priority
To emphasize, the measurement of an artifact's priority occurs in two ways. Firstly, by its progress towards completion. Secondly, by its ranking each step of the way.
In general, the higher priority work should be moving up and right on most boards. Conversely, the lower priority work should remain towards the left, and at the bottom.
Progress
Firstly, progress indicates how far down the path is the artifact. On the WMS boards, the movement of the artifact from left to right indicates progress. Artifacts to the left should have lower priority than artifacts to the right. In other words, work to complete items already underway takes priority over starting something else. Otherwise, an ever-growing number of artifacts are "in process" and few, if any, ever complete.
Ranking
Secondly, ranking indicates relative importance of one artifact, as compared to others, in the same State. On the WMS boards, the placement of artifacts within a column, from top to bottom, further indicates priority. In effect, artifacts lower in a column have lower priority than those above. Indeed, column placement is always a forced ranking. That is, no two items ever have the same priority within a column. As resources permit, the next item(s) worked should be those at the top of a column.
ITM Artifacts
To conclude the Portfolio Task 4 (PT4) reference information, the following summarize the artifacts which relate to this task.
ITM Artifacts: PT4 - Inputs
Specific input will vary depending upon the type of artifact indicated by each Elaborate Story. Look to the inputs related to the parent Feature (Request), for some examples.
ITM Artifacts: PT4 - Outputs
As with Inputs, Outputs will vary depending upon the artifacts each Story produces. Again, look to the outputs related to the parent Feature (Request), for descriptions of individual artifacts.