This part of Portfolio Management (PPM) describes the fourth of four (4 of 4) Portfolio Tasks to manage Requests for Change related to the Iterative Transformation Model (ITM). In general, these tasks facilitate IT Solution definition, as well as definition of the Epics within each Solution.
Although Portfolio Management borrows many of the concepts and tasks from Solution Delivery, here is one very notable difference. Implementation Task 2: Story Analysis describes how delivery Stories are made "Ready". Subsequently, Implementation Task 4: Story Build describes how further work on those same Stories takes them from "Ready" to "Done".
In this case, Portfolio Task 4: Elaborate Stories is not a continuation of Portfolio Task 2: Ideate Stories. Rather, Elaborate Stories represent new, separate actions and artifacts that conclude Portfolio Management.  In addition, they facilitate the successful transition from Solution Definition, on to Solution Delivery. For more info about this topic refer to the Portfolio Approach - Reference.
After reviewing the content of this page, check out the additional information on the following topics.
Mise en Place: Artifacts to Build a Solid Foundation for Change
The Elaborate Stories Board is used to manage several, related activities. To illustrate, the table below depicts the columns of the board. Previously, the TMO selected Features (Requests) for Elaboration during a Release Planning Event. It added those Features to the Release Backlog. Correspondingly, related Elaborate Stories, each representing a single artifact to define how best to fulfill the Request, also begin in the Release Backlog. In due time, completing the artifacts prescribed by the Elaborate Stories, drives IT Solution definition. In short, the board conveys the following aspects:
Elaborate Stories Board
| To Do | In Progress | Stakeholder Review | Ready for Sign-Off | "Done" |
|---|---|---|---|---|
| Parent Feature (Request) is in a Portfolio Release. Elaborate Stories here are those selected from the Release Backlog during a Sprint Planning Event. | The current Work-in-Progress (WIP) for defining the Solution. Typically these Stories are worked prior to, or during, Solution Phase Inception. | Given their complexity, nature, and impact to the Portolio, WIP artifacts go through an evaluation allowing stakeholders to raise questions, comments or concerns prior to seeking sign-off. | This artifact supporting the overall Feature (Request) is now complete. Sign-off of the artifact is sought. | Sign-off for the related artifact is received. No further work on this item is expected. |
| Stories here to be completed by Sprint end. NOTE: Solution cadence has not yet started; these are Portfolio Sprints, not Solution Sprints. | While here, the related artifact is being created / updated. | While here, the related artifact is out for peer and Designated Reviewer review. | While here, the related artifact is awaiting final approval and sign-off by the designated individual(s). | Elaborate Stories remain here until the initial round of Solution Release Planning concludes, at which point they are removed from this board. |
| Step 1 | Step 2 | Step 3 | Step 4 | Step 5 |
1. Schedule Elaboration Work
- To begin, a Feature (Request) progressing to 'Solution Options' is the trigger to add the first set of related Elaborate Stories to the Release Backlog. Basically, this set represents artifacts that guide the identification and recommendation of alternatives, along with estimation of resources.  While PT3: Step 2 of 6 suggests a Story set, each organization determines an artifact set appropriate for certain Request types. Additionally, these Stories allow for the creation, and reuse, of both Story and artifact templates. As a result, these will speed up the Elaborate tasks.
- Afterwards, a Feature (Request) progressing to 'Solution Selection' is the trigger to add the second set of Elaborate Stories to the Release Backlog. Generally, this set represents items that guide procurement of software, hardware and services, as applicable. Moreover they guide Solution's Strategy & Architecture development. When applicable, they also guide Level 3 Process Definition. PT3: Step 4 of 6 suggests a Story set. However, each organization will determine a set suitable for their needs.
2. Manage Progress Across Multiple Requests
- The TMO manages completion of each Elaborate Story through Elaborate Stories Steps 1 – 5. In effect, each step represents a hand-off in ownership or accountability for completing the work expected at each step along the way.
- Moreover, sequencing Elaborate Stories for dependencies and priority allows the TMO to focus upon the items which can provide the most value to the organization. For instance, this task provides the flexibility to prioritize conclusion of IT Solution definition for a given Request, over other, perhaps unrelated, items also needing work.
3. Conclude Solution Definition for a Pending Phase
- Specifically, Elaborate Stories represent the systematic aspects to establish new Epics and/or Solutions, each of which define new, manageable segments of change. Step-by-step, the means by which to fulfill a Request come into sharper focus. Moreover, the right actions occur at the right time, preventing groups from getting ahead of themselves. Doing so helps ensure an organization applies its limited resources where they can provide the most value.
- Once all Elaborate Stories are complete, the Portfolio Management aspects of the parent Feature (Request) are complete.
Portfolio Task Boards
Portfolio Task 4 - Elaborate Stories manages these steps. It governs the activities in the lower-right quadrant of the 4 Portfolio Task Boards as depicted.
Significantly, these steps permit an organization to manage the definition of individual Solutions, as well as the Epic(s) within each. The Stories which progress through them represent production of the items which take a Request from "Ready" to "Done", from a Portfolio Management perspective.
Accordingly, the Stories define what happens in support of a Feature (Request) after its selection for Elaboration during a Release Planning Event. Similarly, each Story appearing on the board represents an item selected for development during a Sprint Planning Event. Completion of each adds another item to the framework that supports fulfillment of the Request.
The child pages above describe each of step of the process in detail.
This is the final Portfolio Task used to manage ITM related Requests for Change. Solutions which progress from Portfolio Management transition from Solution Definition to Solution Delivery. Further work on the Solution is driven by Iterative Solution Planning and Iterative Solution Implementation.
After reviewing the pages listed above, review Epic Lifecycle Management and Capability Lifecycle Management to see how certain Customer Requests for Change continue to track across the Solution Portfolio.