The second of five (2 of 5) levels in the ITM's Iterative Planning Approach produces the Solution Roadmap. Basically, these tasks identify and prioritize incremental changes to the Solution and set the long-term objectives for the upcoming Phase of work.
Having set the Solution's direction and broad scope, this next level of planning seeks to identify increments of Business Value the organization plans to add the Solution. Ideally, such increments should allow some Customer segment(s) to benefit from the Solution.
In most cases, this involves grouping and prioritizing individual Features into one or more medium-term Releases anticipated to occur within the pending long-term Phase. As a result, all stakeholders receive clear direction as to the general order in which work should progress.
Visualizing and Prioritizing Long-Term Work
Roadmap Planning takes the Level 1 planning outputs – Vision and Epic List – and begins to identify and coordinate the incremental changes to achieve the envisioned Solution. To rephrase it, these tasks take the larger, long-term changes implied by the business functions and objectives in each Epic, and break them down into more manageable, medium-sized changes.
Medium-sized changes relate to individual Features. In short, the idea is to take the large, rather unspecific scope each Epic implies, and drive that to the next level of detail. At this point, it is sufficient to identify as many potential Features as possible and provide some basic information for each. Full definition of each Feature occurs in the next planning level, after prioritization.
In addition to breaking down Epics into Features, rollout planning looks at work which may fall outside of individual Epics, yet is nonetheless expected in order for Customers to begin using the Features delivered. Finally, all of the work is prioritized and grouped to help plan the long-term and allow stakeholders to visualize a roadmap of what's coming for this Solution.
Epics into Features
Features represent medium-sized Solution increments. That is, the change each Feature defines is smaller than than the larger-scale changes its parent Epic represents. Similarly, the change is larger than the small-scale changes each child Story defines.
In general, Features define increments by which the Solution advances. Another way of looking at Features is that they describe increments of "Business Value". To rephrase it, Features define 'What' a Customer wants.
At this point, the addition of any Feature to the Solution Backlog requires only three (3) attributes:
- Name / Title / Summary: A short phrase, giving a name and some implied context to the Feature;
- Benefit: A short description of the Feature's benefit(s) to the Customer. If there are multiple benefits, then list each. These describe the 'value' to the Business; and
- Size Estimate: A preliminary T-Shirt size, described below, indicating the anticipated effort required to deliver the Feature.
Further definition of each Feature occurs later as part of Analysis & Design, Although, that does not happen until after prioritization of Features on the Roadmap. For additional information, look to the first of four (1 of 4) Implementation Tasks, Feature Planning.
Adding Features to the Solution Backlog
To begin, Solution leaders simply add unrefined Features to the Solution Backlog. To explain, unrefined means that little effort is made to define specifics about the Feature at this time. Rather, defining a Feature occurs later, during Feature Planning. In most cases, the Feature's Name and Benefit(s) come first. Afterwards, once most Features are in the backlog, then estimate their size. Other Feature attributes come later. At this point, they are pretty much placeholders to use for high-level Solution planning purposes.
Give each Feature a unique Name. Depending upon the Work Management System (WMS) in use, this may represent a Feature's Title or Summary. Whereas Story names or titles employ a standardized naming convention along the lines of ‘As an <actor> I want <action> so that <achievement>’, Feature Names or Titles follow a different convention. For reasons explained later, most use a nomenclature similar to the following:
<Feature Group> – <Solution Function> – <Entity>
[Required] [Optional] [As needed]
Feature Name
A 'Feature Group' allows multiple Features with similar characteristics to relate to one another. A Feature Group may use a Business Process Definition Action, such as a Process, Activity or Task Name. Alternatively, it may indicate some subset of Integrations or Data Migrations, such as those from a given source system. Basically, Feature Groups offer a means by which to organize change in addition to Epics and Themes.
A 'Solution Function' indicates the Component function(s) to which the Feature relates. For instance, a Solution Function may reflect an application menu selection. Alternatively, it may segment one Business Value increment from another, similar increment, such as a specific Operational Activity. Likewise, for Integrations or Data Migrations it should identify the general content to move, such as 'Customers' or 'Timesheets'.
Feature Group labels can span multiple Epics. Conversely, a single Feature may cover all functions within some portion of an Epic. In the latter case, Feature Group and Solution Function may effectively become the same. Finally, for Solutions in which multiple Business Segments or Customer Groups use the same Solution Function, appending an 'Entity' to the Feature Name allows for MVP level Features, as described below.
Sample Feature Names look like the following:
- Manage Quote – Create Quote – Medical Device
- Manage Quote – Create Quote – Pharma
- Manage Quote – Validate Compliance
- Bank Integrations – BofA Lock Box Receipts
- Create Sales Order – Enter Order
- Create Sales Order – Add Pricing – North America
- Create Sales Order – Add Pricing – EMEA
Feature Benefit
Secondly, list the Benefit(s) associated with this Feature. It is important that stakeholders recognize and understand the difference between Features, Benefits and Value. In short, to paraphrase from the link, and to put it in ITM context and terms:
- The Solution defines the Features;
- Business Segments define the Benefits;
- Customers define the Value.
Feature Size Estimate
Afterwards, leaders roughly estimate the size of each. By definition, a Feature's size must be smaller than that of an Epic, which can span multiple Releases, and larger than that of Stories, which must fit within a Sprint. Moreover, there is a size limit for any individual Feature. Specifically, every Feature must be small enough to fit within maximum timeframe permitted by the Solution's Release cadence. See below for guidance on estimating Feature size.
Identifying Increments of Business Value
To begin, let's define "increments of Business Value". As with other Agile terms, it can have various meanings. Although, in the ITM its use is rather explicit. Accordingly, understanding what it means provides helpful context.
Basically, from an iterative perspective Business Value refers to a common type of mid-level Solution scope. In other words, in the Epic > Feature > Story hierarchy, individual Features represent most increments of Business Value.
Each increment provides some value to some customer segment. However, now is not the time to define Features. Rather, merely to identify and prioritize them. Later, their definition occurs in the next planning level.
Large, Medium, and Small Scope
To explain, at the large end of the spectrum, Epics list business actions to implement along with other objectives to achieve. In effect, each Epic defines some Solution scope in the broadest, least specific terms.
Conversely, at the small end of the spectrum, Stories correspond to individual additions to functionality. To put it another way, each Story defines some Solution scope in the narrowest, most specific terms.
In the middle, Features list benefits anticipated for a given business action, and given Customer segment, that some set of functionality will enable. That is, Features define some Solution scope smaller than an Epic and larger than a Story.
Moreover, to represent Business Value Feature scope must be sufficiently useful that, if properly delivered, one or more Customer segments may choose to use it. To rephrase it, Features describe the 'What' that some Customer wants.
An Example for Context
For example, consider the following.
At the large end of the spectrum, a Sales Epic describes an organization's desire for change relating to the business actions:
- Manage Forecast & Opportunities;
- Manage Quotes;
- Review & Approve Quotes;
- Create Contracts;
- Present to Customer; and
- Convert Quotes to Orders.
Further, the Epic's objectives include consolidating five legacy systems, each used by a different Business Segment, into a single, global platform, as well as enabling all functionality in English, Spanish, and German. Obviously, this Epic describes rather broad, and not very specific, scope.
It would be rare to deliver an entire Epic's scope in a single increment. If that were to happen, then it would need to be a very small Epic as well as a very large increment.
At the small end of the spectrum, while individual increments of functionality each add value to the overall Solution, each Story used to represent each functionality increment is unlikely to be sufficient for a Customer to chose using the Solution over some existing alternative.
Of course, in between the large and small ends some group of functional increments are likely sufficient for some Customer segment to use some portion of the Solution. That is, some group of functionality that exists between 'all' and 'nothing'. This is the level of 'Business Value' that each Feature describes. To emphasize, it is important to understand that Features are never meant to be all things to all Customers. Rather, they should be the minimal thing for at least one Customer.
Differentiating Features and Stories
To continue the example, the Epic's 'Manage Quotes' objective may imply the need to Enter a Quote. Another functionality increment might be for a program, or job, to ensure each Quote conforms to regulatory constraints or pricing guidelines. Another increment could be the ability to print a Quote, or produce a Report that summarizes several Quotes.
Would the ability to Enter a Quote in three languages, but not to process or print a Quote provide value to anyone? Likely not. How about entering, processing, and printing in one language? Indeed, that may help at least one Customer segment. Moreover, this provides opportunities to learn from, and reuse, much of this work to produce similar functionality in other languages.
Of course, a single Story describes each functionality increment. Accordingly, each Story must describe rather narrow, and very specific, scope. How an initiative chooses to group those Stories has a big impact on Features. Unfortunately, there is no hard and fast answer as to what a Feature should or should not entail.
To differentiate what each initiative chooses to call a Feature, time is a helpful guide. In a small, simple Solution, a Feature may involve entering, processing, and printing a Quote. Conversely, in a larger, more complex Solution, Enter, Process, and Print Quotes may each be their own Feature.
Determining the difference is based largely on the timeframe needed to build each increment. If the work to enable Enter a Quote can be completed in less than Sprint, then it may be a Story. If the work requires longer than a Sprint, than it is likely a Feature which will comprise several Stories.
Guidelines to Follow
The challenge with defining sets of functionality is achieving the best possible scope. In many cases, organizations make the mistake of assuming it is easiest to define a group with the maximum amount of functionality. However, that goes against an important concept known as Minimal Viable Product, or MVP. MVP is important because it provides guidelines for delivering some useful functionality, as quickly as possible, with the least amount of impediments.
For those with waterfall knowledge, MVP is often the complete opposite of that experience. In waterfall, Business Segments often get just one bite at the apple. That is, they are given only one opportunity to define functionality they want. As a result, they make every effort to include all possible functionality, along with every bell and whistle they can think of. Moreover, as new ideas arise, requirements change, even after functionality is built. MVP is pretty much the opposite.
In effect, MVP seeks to provide, initially, just the most basic functionality that is useful. Thereafter, subsequent changes provide improvements based on initial feedback, and/or adding bells and whistles. To be sure, this is a cultural change for any organization, or participant, expecting a waterfall approach. Try to stuff more functionality than needed into a Feature and overall delivery occurs more slowly, actually provides less value, and results in a less robust future-state.
So, what's the best possible Business Value scope? In most cases, it is some set of functionality related to one business action, suitable to a single Customer segment, that accomplishes something of value to that Customer. If there are multiple business actions or multiple Customers in the mix, then it is likely not MVP. Undeniably, trying to include multiples of anything increases complexity, which in turn delays making functional value available to some Customer(s).
Breaking Down the Example Epic
Looking back to the example Epic above, it describes six (6) business actions. Although, in reality it is likely that each business action contains several, smaller increments of Business Value. For instance, the organization may rely upon different types of Contracts, for different types of Customers, or types of Quotes. In this case, each Contract type, or Customer type, and/or Quote type is a potential Business Value increment.
Similarly, the number of legacy systems implies at least five (5) Business Segments currently using those systems. In the new, global platform, these become Customer segments. That is, whereas each segment is currently the "owner" of their corresponding legacy system, within the new system the Business Segment defining the global Solution must account for the needs of each user group, or Customer segment.
Furthermore, the three (3) languages imply value increments which likely relate to one or more business actions. For instance, the ability to localize a global action into each language implies there are at least three different value increments for any affected business action.
Potential Value Increments
To conclude the example, let's extrapolate that 6+ business actions, 5+ Customer segments, and 3 languages implies roughly (6 x 5 x 3) ninety (90) potential value increments, or Features. If the Solution has, for instance, 10 Epics. Then perhaps it has over 900 Features. Don't freak out! This is not a bad thing.
On one hand, one purpose of Level 2 Planning is to identify all potential work. The more granular each increment is, the easier it is to identify desired pieces and to spot missing pieces. Additionally, the more specific each Feature is. the easier it is to estimate work. Moreover, the constrained scope increases the accuracy of each estimate.
On the other hand, as described below, dealing with a larger number of narrowly defined Features turns out to require less work, less time, and less cost than trying to deal with a smaller number of Features which combine multiple actions, segments, or languages. Do not worry about the number of Features. Rather, just strive to identify all potential Features.
The concept of Business Value is important. As the classic ATM Cake example shows, there are multiple ways to break down a large objective into multiple pieces. However, not all pieces provide Business Value.
While the horizontal slices are one way to break down the larger Solution, is it not a desireable way to do so. Business Value will be achieved faster, at less cost, and with higher quality by following the vertical example.
Feature Identification
The first task in Level 2 Planning is to breakdown the Vision and corresponding Epics into Business Value slices of work. In general, there are three categories of Business Value increments:
- Business / Technology Features – result from splitting Business Epics or Technology Epics, according to the Solution Type.
- Architecture Features – result from splitting The Standard Epics and capturing other Non-Functional Requirements.
- Tech Debt Features – result from other aspects of the solution, typically affecting multiple Epics, such as tool updates or application upgrades.
Leveraging Business Value, Process Definition, and Minimal Viable Product (MVP)
Each Feature should describe some Business Value smaller than an Epic and larger than a Story. Accordingly, inputs to help identify and scope Features include:
- A related Business Process Definition and its content, such as Work sequence, Actions, Roles, etc.; and
- The concept of Minimal Viable Product.
On one hand, each Business Process Definition describes the organization of multiple business actions, including Activities, Tasks and Steps, to achieve some objective(s). For the most part, Business Actions relate to Business Features. In some cases, a single Action may relate to multiple Features. For instance, the same Action as it applies to multiple, different Entities. In other cases, multiple Actions may relate to a single Feature. For example, a Feature may involve some series of multiple, related Tasks.
On the other hand, Minimal Viable Product (MVP) is an approach in which new functionality is sufficient to satisfy initial users, or Pilot groups. To clarify, an MVP level of functionality involves just those core Features sufficient to Release the Solution, and no more. In other words, think of MVP as being a prototype – good enough to use, but likely plenty of room for improvement.
Forward Progress
As noted in several locations throughout the ITM: Features are increments by which the Solution advances; Stories are increments by which the Solution is built. As a result, a primary benefit in targeting an MVP level when defining individual Features is to minimize the time and effort required to complete all Feature-related tasks. That is, to minimize each of the following:
- Refining the Feature to “Ready”;
- Identifying and refining all related Stories;
- Development, test, and approval of all Stories; and
- Certification testing, when appropriate.
Over time, design and develop a complete, final Feature set only after considering initial user feedback. Indeed, gathering insights from an MVP is quicker and less expensive than developing more, or more evolved, Features. To rephrase it, trying to achieve end-state on the first attempt increases costs and risks. For instance, any portion of a Solution may fail due to incorrect assumptions or overlooked requirements.
MVP is the most pared down version that can still be Released if it meets 3 key characteristics:
- It provides enough value that people are willing, and able, to use it;
- It demonstrates enough future benefit to retain initial users; and
- It provides a feedback loop to guide future design and development.
A caveat to this approach is that it requires the initial users to be aware of the long-term Vision and objectives of the future-state Solution. That is, the first group(s) to pilot new functionality must expect to provide the feedback necessary to guide future development. Moreover, everyone must recognize, and agree, that MVP is not the end-state.
Slicing & Dicing Related Features: Not all Work is Equal
There is a secondary, and very valuable benefit to using MVP. That is, the Business Value one Feature describes is frequently applicable to other, related Features. To clarify, by focusing on just one objective initially, any remaining objectives require less work, less time, and less cost. Recognizing related Features is an important aspect of breaking Epics into Features.
To explain, each business action often applies to multiple Business Segments and/or Customer Groups. As a result, it is common for a related Feature to occur with multiple flavors. In other words, differences which apply to one segment vs. another. For example, a business action such as ‘Create Quote’ may be similar, if not identical, across Sales divisions.
Accordingly, after creating an initial MVP version for the first Business Segment, Teams may copy, modify, and reuse the Feature, for a second and every subsequent segment. In addition to Feature reuse, all items related to it – Stories, Code, Tests, Operating Procedures, etc. – also become candidates for reuse. As a result, one goal at a time saves significant time and effort.
Moreover, each reuse also offers opportunities to incorporate additional, incremental value to earlier Release(s). Furthermore, it also allows for improved quality. In other words, each reuse is also an opportunity to incorporate enhancements. The following hypothetical examples help explain why not all work is equal.
Example for Reuse & Recycle Benefits
Indeed, reuse of prior work is one of the major benefits of an iterative approach. To explain, it takes a certain amount of effort to take a Feature from initial identification through to its availability in Production. In short, a list of the work required includes the following. To illustrate, each Feature icon represents all of this work for a single Feature.
- Identifying and refining (grooming) the Feature itself (Feature Planning)
- Identifying and refining all Stories related to the Feature (Story Analysis)
- Planning for delivery of the Feature (Release Planning)
- Planning for building of the Stories (Sprint Planning)
- Developing and testing each Story
- Evaluating and accepting all Stories to validate the overall Feature
- Certification testing of the Feature
Regardless of a Feature’s size, let’s assume that all of the work listed above constitutes 100% Effort to deliver the Feature.
At this point, consider the added dimension that many such Features apply to multiple Business or Customer segments. In various cases, the same (or similar) Feature may be (re)used over 2, 3 or more separate segments.
For the purposes of demonstrating alternate considerations when planning a Solution Roadmap, let’s begin with a very small amount of some assumed volume of work. In this example, the work contains three (3) Features - F/A, F/B and F/C. Each Feature corresponds to one business action. Moreover, three Customer Groups, or Entities - North America (NA), Europe (EUR) and Asia- Pacific (APAC) - each use all three actions.
Furthermore, while each Feature delivers an MVP level of functionality itself, recognize the Customer may or may not choose to Rollout any functionality to any group until all three Features related to a given group are available.
Designing Features for Reuse: Demonstration of Alternatives in Feature Definition
Of course, there are several considerations when determining how to organize and prioritize these sample Features.
In general, the effort to deliver an initial Feature, as described above, recognizes that when creating the 1st Feature Build there are:
- No existing Features / Stories to leverage;
- No existing code or tests to leverage;
- No lessons learned, and No User feedback
As a result, it requires 100% effort to produce each artifact.
However, on the 2nd Feature Build of a related Feature there are now artifacts from the initial Feature to leverage:
- Some existing Feature / Stories;
- Some existing code, config, and/or tests;
- Some lessons learned; perhaps No User feedback
Given the existing artifacts available, let’s assume a related 2nd Feature Build requires 50% effort as compared to the initial 1st Feature Build.
By the 3rd build, particularly if the 1st Feature Build is in use by early adopters, there now are:
- Existing Features / Stories to leverage;
- Existing code and tests to leverage;
- Lessons learned after 2 prior builds;
- Feedback from hands-on Users.
Given these resources available, let’s assume a 3rd Feature Build requires 50% effort of the 2nd Feature Build, or 25% effort of the 1st Feature Build.
To illustrate, the reduced effort associated with each Feature Build corresponds to the smaller Feature icon.
Avoid the non-MVP Pitfall !!!
There is a mistaken belief that when a business action applies to multiple groups, there should be economies of scale in building one Feature to concurrently address multiple groups. However, those perceived economies of scale are false! In reality, for just two (2) groups, actual effort more than doubles. Moreover, for each additional group the amount of work required, and corresponding delay in delivery, tends to increase exponentially.
For just two groups in one Feature, in addition to the need to double some efforts (still need planning for both, requirements for both; tests for both, etc.) there is also the added complexity of having to merge (and/or split) these aspects, as well as having to juggle alternative, sometimes conflicting items. This is not MVP!!!
To emphasize, MVP is about keeping it simple, and allowing for each state of Feature delivery to progress as quickly and directly as possible.
Benefits of MVP & Reuse
If we agree on the basic premise that reuse of prior artifacts can lead to reduced effort in delivering incremental business value, or related Features, then we can further explore how choices to organize and prioritize those Features on a Roadmap can lead to significantly different outcomes.
When considering how to identify and arrange Features in order to deliver the assumed volume of work described above on the Solution Roadmap, there are alternatives which can enhance (or deter) delivery time, cost, and value to the business. The following examples explore different scenarios.
Example 1 - Features Without Dependencies
In this first example consider Features which are not dependent upon one another. In other words, work on Features A / B / C can all progress in parallel. Furthermore, assume there are 3 Teams able to work in parallel.
EX1: Alternative A
Alternative A depicts each Team working on the same business actions, in the same sequence, each targeting one Entity. In this case, there is no opportunity for any Team to leverage or reuse prior work, and delivery of initial functionality to the Customer occurs only after the 3rd Iteration.
In summary, through the end of the 4th Iteration, Alternative A allows Teams to apply 3 additional work efforts (1 Iteration for each Team) to some other tasks, and Customers may use new functionality for one iteration.
EX1: Alternative B
Alternative B depicts the scenario described above where two groups are combined into each business action. In this example, the added complexity expands effort to 250% for each Feature. Although, there are materials to reuse for the 3rd group, meaning each of those Features requires 50% effort. As a result, overall delivery of initial functionality for each Customer group still occurs only after the 3rd Iteration.
In summary, through the end of the 4th Iteration, Alternative B allows Teams to apply only 3 additional work efforts (1 Iteration for each Team) to some other tasks, and Customers may use new functionality for one iteration.
EX1: Alternative C
Alternative C depicts a scenario where each Team delivers one business action, with each Team focused on delivery for one group. In this case, each Team has the opportunity to reuse Features and leverage other artifacts twice for each business action. Accordingly, the three (3) Feature builds require 100%, 50% and 25% respectively. As a result, overall delivery of initial functionality to one group occurs after just the 1st Iteration. Whereas delivery to the remaining two groups occurs after just the 2nd Iteration.
In summary, in the same amount of time as Alts A & B, Alt C allows Teams to apply 6.25 additional work efforts to some other tasks. To emphasize, this is more than twice the other alternatives. In other words, more than 1/2 of their comparable time is available to deliver additional value elsewhere. Furthermore, one Customer group is able to benefit from new functionality for three (3) iterations, while the remaining two can realize two (2) iterations of value. Again, this is more than twice the benefit of Alternatives A or B.
To conclude, earlier access to functionality means greater value to the Customer. Furthermore, the reuse of each Feature, multiple times, also improves overall quality by allowing Teams to incorporate initial user feedback in to later increments of similar functionality.
As shown above, choices of how to organize and prioritize a simple Feature set leads to vastly different outcomes. Imagine how using MVP properly over hundreds of Features can add up to significant resource savings.
Example 2 - Features With Dependencies
In the prior example, delivery of any Feature could occur in any order. Choosing the proper order drove various benefits. In many cases, it is not feasible to deliver Features in any order.
In fact, it is often the case that some work must occur before other work can begin. Whether to provide enabling functionality or merely to follow operational work flow, Features often are dependent upon one another.
When dependencies exist, for example Feature A must be delivered before Feature B can begin, the cumulative work efforts remain the same. However, there are now different considerations.
EX2: Alternative A
As in the original example above, Alternative A depicts initial functionality delivered to the Customer after the 3rd Iteration. Because these examples include an additional iteration, in this case it allows Teams to apply 6 additional work efforts - 2 Iterations per Team - to some other tasks.
EX2: Alternative B
Alternative B does not deliver any functionality until the 7th or 8th Iteration. This follows the similar example above of combining multiple groups for each business action. On one hand, it does allow Teams to apply 9.5 additional work efforts over the first 5 Iterations. However, considering those should be lower priority Features based on the Solution Roadmap, is this equivalent additional value?
In short, Alternative B is a good example of planning work in the worst way possible. Unfortunately, it is also a depiction of what many organizations choose to do.
EX2: Alternative C
Alternative C delivers its first functionality to one group after the 3rd Iteration. Moreover, remaining functionality is available to all after the 4th. On one hand, later access functionality as compared to Alternative A means 1 iteration of less value to two Customer groups.
Comparatively, this also allows Teams to apply 9.75 other work efforts over the five Iterations to deliver additional value. To rephrase it, the outcome is the same for APAC. While NA & EUR benefit one iteration later, their delivery requires 2.5 work efforts, as compared to 6 in Alternative A.
Furthermore, Alternatives B & C both allow for the removal of an entire Team while still delivering the volume of work desired. Although, that correspondingly reduces additional work effort available in each scenario. Conversely, keep the third Team to produce even more value.
Hopefully, these examples demonstrate that trade-offs to consider when identifying and sequencing Solution Features can greatly affect resource requirements and timeframes.
Estimating Feature Size
Previously, the topics explained how segmenting and sequencing the overall Solution into Features can reduce time and cost, as well as increase Business Value. Although, a key enabler for effective planning and proper sequencing is an ability to gain a good estimate of the effort each, individual Feature requires.
Unlike Story estimates which use Points, Features estimates use T-Shirt sizes. Basically, the size estimate for a Feature may go through three (3) stages. In general, the 1st and 2nd stages are appropriate for Level 2 Planning; the 3rd stage applies to Level 3 Planning.
Depending on the anticipated complexity of design, build, and test activities, a Solution Owner alone may estimate a Feature's size. Although, more typically, they also include input from the Customer, Delivery Team, 3rd Party Solution Provider (where applicable), QA, and/or the Enterprise / Solution Architect.
Stage 1: Preliminary, Relative Estimate
To begin, an initial, rough estimate suffices. In this case, estimators can use relative sizes to compare the “bigness” of one Feature to another. In this case, use the same Fibonacci approach (see below) used for Stories. However, because Features are larger than Stories, both their lowest and highest estimate values are larger than those of Stories. Accordingly, the T-Short size series begins at 13, rather than 1.
Stage 2: Gross, Absolute Estimate
The Relative Estimate is fast and straightforward, However, the increasing range between each number in the series can leave some pretty big uncertainty in prioritization. When possible, estimators can use an historical comparison as the basis for a better, more reliable estimate. In this case, gauge a new Feature’s size by the cumulative Story Points required to deliver some comparable Feature(s) from prior iterations.
Stage 3: Derived, Absolute Estimate
Finally, when the reliability of an estimate must be further improved, a Team can break the Feature down into it component Stories. Afterwards, they estimate individual Story Points. Of course, the sum of the estimated Points derives the most refined and accurate estimate of a Feature's potential scope and cost.
Fibonacci Refresher
For anyone not familiar with the Fibonacci series, it begins at 1 and then adds the preceding number to derive the next number. As a result, start with, 1, then 2 (1 + 1) followed by 3 (2 + 1), and so on. In short, the series begins with 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 600, etc.
The Fibonacci series is good for initial estimates of unknowns like Feature and Story work effort. Basically, this is because the spacing between each number grows as the series progresses. In effect, this increase in series values reflects the lack of understanding, or certainty, of larger pieces of work as compared to smaller ones.
Thus, at the small end of the series, the smaller the amount of work, the better understood it generally is. Accordingly, it receives a smaller Fibonacci number. Conversely, at the other end of the series, the larger the amount of work, the less understood it is. Hence, it receives a larger Fibonacci number.
Maximum Feature Size & Release Cadence
For the same reasons that each Story must be small enough to fit into a Sprint, each Feature must similarly be small enough to fit into a Release. A Feature that spans Releases causes the same problems as a Story that spans Sprints. In short, they invalidate many iterative planning, implementation, and reporting rules.
In other words, a Feature cannot span more than one Release. As a result, if early estimates indicate a size near or greater than a Team's Capacity for a typical Release, then that is a good indicator the Feature must be broken down into multiple, smaller Features.
To break it down, follow the same techniques described above. Alternatively, follow guidelines used to split Stories. For example, look for smaller, logical segments in things like Process Flows, Groups and Roles, Business Rule variants, and so on. Alternatively, consider using a Spike to conduct further analysis.
And in following MVP, be sure to scale down estimates for Features where a 2nd or 3rd Feature Build can benefit from the reuse of Feature-related items. For example, if the 1st Feature Build is considered Large, perhaps the 2nd Feature Build should be a Medium, or Small, and each subsequent reuse even smaller.
Of course, a correlation exists between Release cadence and maximum Feature size. That is, a Feature cannot exceed a Team's Capacity. For instance, a Solution following a Monthly Release cadence may use Features equal to or smaller than 2 x Team Velocity. Conversely, a Quarterly Release cadence allows for Features equal to or smaller than 6 x Velocity.
Basically, the longer the Release cadence, the larger the maximum Feature size. To be sure, this is an important consideration over a Solution's lifecycle. Early on, when there is a lot of change, it is better use a longer cadence as well as larger Features. In effect, this allows for more change with less overhead.
If a decision to change Release cadence occurs, then Teams must address any Features above the new size restrictions. Alternatively, when the volume of change diminishes to the point at which new Features now have smaller sizes, that could be a good indicator to consider moving to smaller, more frequent Releases.
Initial Delivery to Customers
In conjunction with breaking down the Level 1 Vision and Epics into preliminary Features in the Solution Backlog, it is also time to consider "The Big Picture". That is, what must happed for rollout of the Solution to initial Customers / Users occur?
Whereas the Solution Roadmap (see next) describes the sequence in which to deliver incremental Business Value, the Initial Rollout Plan describes the other aspects of making the Solution available to End-Users. This distinction between these two is the first separation of a Release (build) vs. a Rollout (use).
| Initial Rollout Plan - Topics to Include | ||
|---|---|---|
|
|
|
|
|
|
|
|
|
To clarify, a Release involves delivery of new Solution functionality. That is, the completion of Stories by which the Solution is built, and Features by which the Solution advances. Afterwards, a Rollout encompasses a Release, plus additional considerations.
Indeed, a Rollout may encompass multiple prior Releases. Specifically, a Rollout occurs whenever first-time Users access the Solution, as well as when existing Users access new functionality. In these cases, there is often additional work to consider beyond delivery of new functionality.
Beyond the Backlog
As an example, consider the initial access to a Solution by Customers in some Business Segment. Whether this group is the first to use the Solution, or this is their first-use of an existing Solution, Rollout requires consideration of several enablers. For instance, do the sites where Customers use the Solution have appropriate network connectivity? What policies, procedures, or other knowledge capital might they require? What type(s) of training are appropriate for anyone unfamiliar with new functionality? How will the transition from current system(s) to the new Solution occur?
Moreover, the Initial Rollout Plan offers a succinct summary and orientation to anyone unfamiliar with the Solution. Accordingly, it is often a good artifact
In addition to some ways the Initial Rollout Plan is
A Solution's backlog, and the items contained within it, tend to focus on design and delivery. If the Solution requires all of that is within the control of the Solution, then the backlog
An Initial Rollout Plan can encompass several items which relate to the Epic to Features breakdown described above. Furthermore, it considers several aspects which apply across multiple Epics. It also considers enablers which prepare the organization for the new Solution.
Another way to look initial delivery is to consider things beyond control of the Solution itself. Continuing with the prior example, provisioning of appropriate networking is not something most Solutions deal with. Unless, of course, this is the organization's Networking Solution. 🙂 Likewise with training. Perhaps that is something the Solution controls, or perhaps an independent Learning & Development group produces and delivers training. Regardless, when there is work required which is not something to appear in the Solution's backlog, then it likely belong here.
TBD
TBD
Determining Solution Advancement: Inputs to the Solution Roadmap
Both the Epics to Features, including Architecture & Tech Debt Features, and the Initial Rollout Plan are necessary inputs to produce the Solution Roadmap. Basically, the Roadmap describes the sequence, or priority, in which to deliver individual Features.
For custom software development, it may be possible to deliver Features one at a time. However, for packaged applications, it is best to deliver Features in groups. In some cases, these address larger business actions. In others, they target several actions at the same time.
Regardless of their purpose, each Feature group aligns to a single Release. In other words, the Feature group defines the scope of any Release. Over the course of a Phase, each Release advances the Solution towards its stated objectives.
At this time, the sequencing of Features is merely an estimate. The Roadmap depicts the initial recommendation of each Feature's priority. In doing so, the Roadmap will roughly align each Feature to an anticipated future Release. Planners must take several factors into consideration to do so.
The first task in this planning level tried to identify as many Features as it could. Furthermore, initial estimates help provide context to describe the overall effort anticipated to achieve the objectives of the pending Solution Phase. Based on that volume of work, the organization is able to make several decisions.
For instance, if the volume of work is larger than the organization can manage on its own.
When applicable, another input to consider is any related Process Definition(s), which define the order of Actions to which Business Features relate and the Roles which execute them. This should be the same Process Definition that was used when breaking down Epics into Features as described towards the top of this page.
As depicted in the diagram, dependencies from one process to another, from one business action to another, as well as the Roles executing each action, are all important considerations when adding Features to the Roadmap and sequencing their delivery.
The Roadmap objective is to ensure that the order of Feature development enables the delivery of incremental Business Value with each Release.
The Roadmap provides context for the Delivery Team’s day-to-day work and adjusts to shifts in priority, dependencies, resource constraints and so on. It is comprised of:
- Bars – to indicate increments of work (e.g., Features);
- Lanes – to differentiate between one, select category type (e.g., Theme)
- Markers – to highlight important dates and milestones;
- Timeline – showing months or weeks.
Unrefined Features are selected from the Solution Backlog and added to the Roadmap. They are placed based on criteria such as priority, dependencies, size and resource availability:
- Features to the left have a higher priority than Features to the right (i.e., a Roadmap is read from left to right). Similarly, Features to the right may have dependencies upon Features to the left.
- Size estimates also help order Features and organize them into potential Releases. The cumulative size of the Features planned for a Release cannot exceed the Release Capacity. So a given Release may include one large Feature, several small Features, or any combination of sizes provided their aggregate size is within Capacity.
Sequencing of Features for Delivery: Guidelines for adding Features to the Solution Roadmap
Adding Features to the Roadmap establishes their priority and offers a preliminary alignment of each Feature to a Release. All subsequent planning tasks (PL3, PL4) should work Features from left-to-right as they appear on the Solution Roadmap.
When selecting an unrefined Feature from the Solution Backlog to be added to the Roadmap, consider these two factors:
- Feature Dependence – which drives sequencing. For example, does Feature A need to exist before Feature B can begin? If so, do not sequence them in parallel. It's probably best to not schedule them for the same Release.
- Value Delivery – is based on completing delivery of incremental Business Value. FOr example, if Feature A or B can begin, but completing Feature B will deliver value faster than Feature A, then Feature B should be done first. In other words, prioritize completion and delivery of some scope of business value over beginning some other scope of work.
The Initial Rollout Plan and Business Process(es) will help map out a sequence in which Business Features are best delivered. But be aware of Architecture Features or Tech Debt Features that may need to be prioritized because they are required enablers of a given set of Business Features.
The examples above depicting Roadmap Alternatives A, B & C demonstrated how alternative scoping and the sequencing of Features can affect the time, cost and risk in the delivery of business value – in both positive and negative ways. In addition to the lessons learned from the examples, follow these guidelines when adding Features to the Roadmap:
- Strive to complete areas of functionality and make them Rollout Ready (especially to pilot groups) prior to starting new areas of functionality (i.e., don’t allow multiple areas to be “almost done”).
- For the initial build of new functionality, strive for an MVP-level so that the time and effort to deliver Business Value are minimized, and the opportunity for user feedback and enhancements occurs as quickly as possible.
- Product quality and return on investment will both be enhanced when multiple Releases of any given functionality (i.e., Feature) is planned from the outset.. In other words, build in the idea of getting user feedback to improve a 2nd or 3rd Build of a Feature, which will also provide improvements for the initial recipients, rather than trying to deliver an ideal end-state as part of the 1st build.
ITM Artifacts: PL2 - Inputs
To conclude the Planning Level 2 (PL2) reference information, the following summarize the artifacts which relate to this level.
ITM Artifacts: PL2 - Inputs
Level 2 Planning occurs during Solution Inception, as well as any subsequent Phase Inceptions. Of course, an Inception is not the first Solution-related activity to occur. Indeed, a host of artifacts from prior tasks contribute information relevant to producing the Solution's Roadmap.
From Solution Selection
By the conclusion of Solution Selection, the following artifacts should be available:
From Planning Level 1
Use these artifacts produced during Level 1 Planning for guidance:
ITM Artifacts: PL2 - Outputs
Planning Level 2 concludes once participants finalize the three (3) following artifacts for the pending Solution Phase.
Artifact 1 of 3: Epics to Features
Use the Work Management System (WMS) to capture and manage Solution Features. The act of creating each Feature adds them to the Solution Backlog. In other words, it adds them to the list of items which the Solution may deal with as time and resources permit. Or may never deal with. That is not a decision to make at this time.
To begin, add Features to the backlog for each active Business Epic. Likewise, add Features for The Standard Epics as well. Note that Epics themselves do not appear in the Solution Backlog. Rather, these appear in the Portfolio Backlog when one is in use.
Of course, Solution Approaches offer the initial Features to add to the Solution Backlog. Moreover, Solution Strategies and the Architectural Diagrams may also imply additional Features. In particular, those which relate to the installation and configuration of the core application and any enabling tools.
Initial Review
Thereafter, the Solution Manager should review all Features which align to each Epic with Epic Owners, Business / Process Owners, Solution Owners, and the Solution Architect. The purpose of this review is two-fold. First, to ensure the initial list of Features addresses all work envisioned by all participants. Second, to ensure each is an attempt at MVP level Features.
To emphasize, no Feature should exist in the backlog that does not align to an approved Epic. If there are Features which lack an Epic to align with, then return to the Epic List created initially when Identifying Options. Then progress from there for requisite approvals to add the new Epic(s). If there is not approval for the Epic(s), then the related Features should not progress from the backlog.
Recognize this list is a 'best attempt'. It does not preclude the addition of other Features at a later point. Nor does it guarantee eventual delivery of every Feature. At this point, each Feature requires just three simple attributes:
- a Name (or Title);
- a description of some anticipated Benefit(s); and
- a T-Shirt size Estimate.
There is no no need to provide further information for any Feature until after Solution leadership prioritizes them on the Roadmap.
Artifact 2 of 3: Initial Rollout Plan
Whereas the Feature list breaks down the
The Initial Rollout Plan, when complete, should be available in the Solution's Collaboration Tool (e.g., Confluence).
Artifact 3 of 3: Solution Roadmap
The Solution Roadmap…
- Represents the Vision along a time-scale and is revisited / updated only 2 – 3 times per year
- Is longer-term planning, looking out 6 - 9 months (1 year at most) (i.e., expected results of next 3 – 4 Releases)
- Begins with the breakdown of Epics, adding and prioritizing Features in the Solution Backlog
- Considers the Delivery Team(s) that will be doing the work
- May organize Themes of Features (i.e., swim lane alignment to depict a single type of category)
The Solution Roadmap can be maintained using the Roadmap Planner macro in Confluence, or may be maintained externally using another tools (e.g., PowerPoint, Excel, etc.)