An enterprise idea pipeline provides transparency of your options and allows you to quickly be aware of and respond to high-value work.
—Mario Moreira
Much of Agile implementations focus on the work within a product backlog. This is a good start and helps a team and product owner focus on the development work ahead. When an enterprise is small or focused on just a few products, the initial ideas can go directly into the product backlog. What happens when the organization is medium to large? How do you view the incoming ideas in a timely manner and how do you make investment decisions on where to focus? The answer is via enterprise idea pipeline.
Pipeline of Ideas
The enterprise idea pipeline provides three primary benefits to an enterprise. First, it is a channel that provides an end-to-end flow of ideas from the moment they are recorded to when they are released and reflected upon. Second, it is the enterprise-level portfolio backlog of ideas. Third, it is meant to highlight high-value ideas the moment they come in so that the enterprise does not miss the idea’s window of opportunity.
The culture needed for the enterprise idea pipeline is one where the enterprise immediately considers ideas as they come in because they are based on a current problem or opportunity. You don’t wait for the next budget cycle to consider the idea. The pipeline is a more adaptable way of managing the portfolio of work across your enterprise since ideas can be admitted anytime and feedback may change its priority or reshape the idea. Also, the pipeline brings enterprise-wide visibility and transparency to the work occurring within an organization.
Agile Pit Stop
For an enterprise idea pipeline to operate effectively, it must be in a culture where ideas are immediately considered without waiting for the next budget cycle.
Before moving on, what is an idea? An idea is something that is deemed as valuable but has not yet been created. At the moment it is recorded, it may be small or large. Depending on its level of customer value, it may become work that is worthy of evolving into a product or service.
As part of the Agile galaxy, the enterprise idea pipeline is a working example of the delivery axis focused on delivering customer value, as illustrated in Figure 11-1. As the delivery axis represents the end-to-end flow of customer value from the recording of the idea to the point where it is released and then reflected upon, so is the enterprise idea pipeline.
Figure 11-1. The enterprise idea pipeline is a working example of the delivery axis.
The enterprise idea pipeline is known by different names such as a portfolio backlog, enterprise kanban board, and idea pipeline. What makes all the terms similar is that they imply that the big ideas may eventually (or immediately) be worked on by teams. The enterprise idea pipeline acts as the parent and feeder to all of the product backlogs and helps you connect strategy and ideas to user stories (and even tasks) and vice versa.
An enterprise idea pipeline is primarily used in medium to large companies, when visibility is needed to make investment decisions across portfolios to better understand where the highest-value work lives. It also helps when there are dependencies across multiple products, or when ideas do not have an obvious resting place in a product backlog. When an enterprise is small and made up of a singular product, the product backlog acts as the enterprise idea pipeline as it contains the ideas that may be included in the future of that product. Even at the backlog level, new ideas need to be valued to ensure that the highest-value idea gets worked first. The moment there are multiple products, there may be a need for a portfolio-level backlog that becomes the pipeline for upcoming work.
Path through the Pipeline
As discussed earlier, an enterprise idea pipeline provides an end-to-end view of the flow of ideas from the moment they are recorded to when they are released. It offers a path from idea to delivery. I have found that the Idea Management model established by Emergn is a good way to pattern the flow of work through an enterprise.
Utilizing the first five patterns to form the 5R model, you create a path for your work. As illustrated in Figure 11-2, the five Rs consist of five stages: Record, Reveal, Refine, Realize, and Release. The 5R model is meant to be adaptable. Some companies may decide to use corresponding terms. For example, instead of Realize, the term Develop could be used and instead of Reveal, the term Prioritize could be used.
Figure 11-2. The 5R model as a path to deliverying customer value
Each stage represents a progression of the idea. It is important to note that the path isn’t linear. Some ideas may get to the Reveal stage and are too low in value to move farther. Some ideas may get an increment cut in the Refine stage and then, once in the Realize stage, feedback is received from customers in a demo that find it more valuable, which requires updating the value in the Record stage.
Recording the Idea
The Record stage is a place to begin documenting what is known about the new idea. The documentation should be visible and transparent to everyone in the enterprise. Who typically submits or records ideas? Effectively anyone can record an idea, but more commonly it is a product owner, a portfolio leader, a business or marketing leader, or a manager who is in touch with customers. Recording the idea should include a description, persona or market segment, the value, the risks of doing the idea or not doing the idea, and the assumptions being made. Figure 11-3 illustrates a simple example of recording an idea.
Figure 11-3. Simple example of recording an idea
Within an Agile context, limit the amount of time spent on documenting the idea’s details since the idea has not yet been committed for work. The documentation should provide enough information to gain a general understanding of the idea, but not so much that it is a waste of time if the idea is not selected to work on. For example, avoid writing a bulky business case for the idea since this takes a lot of effort this early in the stage of the idea.
There are several ways that an idea can be recorded. It can be in a freestyle format with the necessary information. It can be in a hypothesis format, as discussed in Chapter 10, along with any additional information. Alternatively, it can be written using a Lean Canvas format. You can learn more about how to capture ideas using a Lean Canvas in Chapter 13.
A key detail for the Record stage is the proposed value of the idea. I recommend using cost of delay (CoD) and CoD divided by duration (CD3) since this provides data on how much money you lose weekly or monthly by delaying the value delivered. You can learn more about CoD and CD3 in Chapter 12. However, other value techniques may be used. Once the idea, including description,persona, value, risks, and assumptions, is recorded, the idea is added to the enterprise idea pipeline, where it gets revealed.
Revealing the Idea
The Reveal stage focuses on two areas. The first area is where the new idea gets revealed in the pool of ideas, according to its value level. The second one is where it is determined if the idea has high enough value so that the owners and stakeholders of value (for example, product owners) and Agile team(s) are notified of the possible work ahead.
The idea gets revealed in the pool of ideas in a rank-ordered manner based on the value that was entered for the idea. This new idea rises to its level of value in the pool, as illustrated in Figure 11-4. If it is one of the top ideas, it will be prominently available for people to view. If it has a lower value, it will sink to its level of value and may not be discussed further. From an Agile perspective, if it doesn’t rise to a high-enough level of prominence, it’s not worth spending more time until it does, if it ever does. The main benefit of this approach is that as high-value ideas come in, they immediately get rank-ordered so they don’t miss their market opportunity.
Figure 11-4. The idea moves into the pool of ideas, where it gets revealed
Who typically reviews and evaluates the recorded idea? Owners or stakeholders of value (such as product owners and chief product owners) and those that help drive investment decisions (for example, business leaders, marketing, and senior management) should be the ones who do this work. They should all have a stake in the success of the work and operate with a discovery mindset.
If the idea floats toward the top of the pool in your enterprise idea pipeline based on its value, several things occur. First, there should be a healthy discussion surrounding the idea. The owner or contributor of the idea should share the details, the risk of doing or not doing the work, how the value was calculated, and the assumptions being made in calculating the value. It is important for the owners of value to periodically check the pool of ideas so that high-value ideas are promptly discussed.
In an effort to continue to validate the value of the idea, stakeholders should challenge the assumptions made that determined the value. Toward the beginning of the idea journey is when the least amount of information is known about the idea. Challenging the assumptions of value is beneficial to the health of the enterprise as it will determine where investments in people and resources are being made. Challenging assumptions of value also reduces gamesmanship of the data’s value.
Let’s consider a hypothetical situation: The owner of the idea assumed that the potential market for the idea included a hundred million customers. However, current data indicates that it is only twenty million. The importance of challenging assumptions is to start with fair assumptions, ergo fair value. More information on challenging assumptions can be found in Chapter 2 (more general) and 12 (specific to value).
Agile Pit Stop
Challenging the assumptions of value is beneficial to the health of the enterprise as it will determine where investments in people and resources are being made.
Once discussion is concluded, changes are made to the idea, which may include updating details about the idea and adapting the value. The idea floats to the level of its adapted value. If it continues to appear that the idea is of high value, it is time to consider the team (or teams) that will work on it and the dependencies the team may have on other teams and resources. Once identified, the team is notified of the idea coming its way. The purpose is to gauge how much work that team already has on its plate. From here, people and prioritization decisions can be made.
When making people decisions, if it is clear that this team is the target for a lot of high-value work, then it behooves the enterprise to add people to the team or adapt another team’s skills to that type of work. When making prioritization decisions, if it is clear that this new idea has a higher value than current work in the team backlog, then a re-ordering of work should occur.
If a high-value idea requires the help of two or more teams, a chief product owner or portfolio leader can gauge how much work each team has on its plates and when it can pull the work into its backlog based on its current velocity during the Reveal stage. The goal by the end of the Reveal stage is for teams to provide a pull signal for the high-value work at the earliest possible moment so the idea misses as little of its market window as possible.
In order for a new high-value idea to get pulled in a reasonable timeframe by the teams, a discussion on slack time should occur. If teams’ backlogs are so full that it is makes it hard for them to pull work in the foreseeable future, then you may not be allowing enough slack in the system. The benefit of slack is twofold. First, slack helps a team consistently deliver on their commitments with quality work since important design and refactoring emerges. Second, slack allows time to respond to emergencies, time to explore high value work, and time for innovation. Without slack, a lot of high-value ideas could easily sit in a wait state for some time.
Refining the Idea
The Refine stage consists of a combination of the team(s)’ beginning to understand the idea, the team(s)’ beginning to decompose the idea into an increment and user stories, and their continuing to validate the value of the idea. When the high-value idea sitting in the reveal pool gets pulled by the team(s), it is ready to get refined. The intent is to move away from the big upfront mindset where months are spent attempting to document all of the requirements. Instead, collaboratively focus on a slice of the idea where feedback is use to gain a better understanding of the value of the idea.
Agile Pit Stop
The intent of the Refine stage is to move away from big upfront requirements and instead focus on a slice of the idea in a collaborative and evolving manner.
Who should be involved in refining and decomposing ideas into smaller pieces? Those that have ownership over products (product owners) and those that self-organize on how to build those products (teams) should be involved. In this case, everyone on the team should be involved including developers, testers, architects, database, and UX. They should all have a stake in the success of the work and be educated and operate with a discovery mindset. Also, you want the whole team involved so that when it is time to build the idea increment in the Realize stage, the full team has first-hand knowledge of the work involved in the Refine stage.
While you may have learned that more than one team is involved in the idea during the Reveal stage, it is in the Refine stage where you learn the details of the dependencies. An idea may cross team and division boundaries. During the Refine stage is when the beginning of cross-team coordination should occur.
It can be challenging to take an idea and decompose it into epics and user stories. One recommendation is user story mapping. The short-form story mapping is both a visual practice that provides you with a view of how a user might use an idea (in other words, the product or service) and a decomposition practice that helps you consider how you may incrementally decompose the idea. Established by Jeff Patton, the visual portion helps the team understand the customer experience by imagining what the customer process might look like. This encourages the team to think through what the customer finds as valuable.
The decomposition portion of story mapping allows the team to think through a number of options of the customer experience, cut a slice of the idea as illustrated in Figure 11-5, and get feedback from the customer. The options within the slice become epics and user stories that represent the user experience. This helps both validate the value of the idea and ensures the idea is being built in a way to provide the best customer experience.
Figure 11-5. Decomposing the idea into options and cutting a slice using story mapping
A benefit of story mapping is that as you work incrementally, one slice at a time, you validate the value that has been ascribed to the idea. Instead of building the whole idea over months, you build a slice and then get actual customer feedback as to the value of the idea. The feedback is used to adapt toward customer value as well as to update the idea record and the value score.
You should only cut one slice at a time. You may learn that the first slice either provided the value or that the customer didn’t find the idea valuable enough to move further. You can learn more about the details of story mapping and how to implement a story-mapping session in Chapter 16.
Agile Pit Stop
Cutting increments of work via story mapping or use cases can help determine the value of an idea prior to the whole idea being built.
There are other ways to decompose ideas into increments. Use cases can be used to map interactions between actors (which can be personas) and a system within a particular environment to achieve a goal. Much like story mapping, the goal is to cut a slice or increment of work that represents one of those interactions and then show it to customers or users to get feedback on the value of the idea and the customer interface.
Another activity that helps decompose and, more importantly, better understand the business and technical detail of the work is the act of grooming (also known as Scrum refining). The end goal of the Refine stage is that you have a slice of work from the idea that should be in the form of epics and user stories that can be placed into your product backlog. Another goal is that you are aware of the dependencies and risks that can impact the work ahead and begin mitigating them.
Realizing the Idea
The Realize stage is the art and practice of building the idea into a working product. Commonly known as product or software development, it is the art of developing a product in a methodical manner. All team members who engage in building a product are involved in the Realize stage. Those involved should include all cross-functional team members such as development, quality assurance (QA), database, UX, documentation, education, and configuration management—effectively anyone who has the ability to turn the idea into a piece of customer value.
Agile Pit Stop
The PO prioritizes the work in the backlog, shares business context with the team, and incorporates customer feedback to better align with customer value.
In the Realize stage, the product owner has a strong role to prioritize the work in the backlog according to customer value, to share business context with the team, and to incorporate customer input and feedback as the idea evolves to better align with customer value.
In the Reveal stage, you may have learned that there is more than one team involved in building the increment of an idea. In the Refine stage, the teams should work together to cut the first increment. Now in the Reveal stage, the teams should establish communication touch points such as Scrum of Scrums to coordinate and collaborate as they build their pieces of the increment.
Within the Agile galaxy, it is in the Realize stage where you typically see Scrum and Kanban occurring. Irrespective of what Agile process used, an iterative process should be applied so that you can iteratively plan, build, inspect, and adapt the deliverable toward customer value.
The primary activity involved in the Realize stage is to develop an idea. From the Refine stage, the epics and user stories from the slice or increment make their way into the product or team backlog(s), as illustrated in Figure 11-6. The team(s) should further groom the epics into user stories and gain more detail about the user stories. From there, an iterative approach should be used to develop and test the product.
Figure 11-6. Work flows from the Refine stage into the backlogs
Iterative and incremental Agile engineering practices should be applied in the Realize stage. This may include eXtreme Programming (XP) practices such as pair programming, continuous integration, test-driven development, collective code ownership, refactoring, and more. Also, integration testing should occur for those instances where two or more teams are working on an idea. This should include system, performance, load, and any other tests that may be needed. The goal of Agile is that when the product is completed at the end of an iteration, it should be potentially shippable.
Because the Realize stage results in a potentially shippable product (that is, something to actually see), customer feedback loops should be used to validate if the idea is valuable to customers. There should be a concerted effort to invite customers based on personas to the demonstrations to gain valuable feedback to ensure the idea is being developed in the direction of customer value. Also, sales and marketing may initiate a launch plan for making current and potential customers aware of the new or updated product.
Releasing the Idea
The Release stage is the activity that converts the in-house built idea and launches it into the public, as illustrated in Figure 11-7. The goal of Agile is that by the end of an iteration, it should include activities to make the idea potentially shippable. Then there may be final integration testing, code preparation, packaging, and launch activities in release.
Figure 11-7. Launching the idea into the market
In some cases, there may be final integration activities, particularly when there are two or more teams working on an increment of an idea to ensure both pieces execute together. Final integration testing provides an opportunity to perform final testing to include system, integration, performance, load, and any other tests that may be needed. This should be limited since such testing or a significant portion should occur in the Realize stage.
Code preparation and packaging begins with version controlling the code used for the release. From there, activities vary by production platform. For a web site, identifying executable code and updating the website with the new code may be all that is needed. For mobile applications, packaging the new release onto an app store for people to download and providing any terms and conditions may be enough. For on-premise products where they are installed onto desktops and servers, setting up a downloadable web location for code or burning the code onto disks, packaging user guides, and crafting terms and conditions are part of the process.
Another aspect of the Release stage may be to execute the launch plan drafted by marketing and sales. This activity communicates to the current and potential customers a bit about the new increment that is now on the market. Once a release occurs, you should update the enterprise idea pipeline showing that the first increment has been released.
Reflecting on the Idea
The five stages of the 5R model have been explored: Record, Reveal, Refine, Realize, and Release. Some collapse the 5R model to 4Rs (Reveal, Refine, Realize, and Release). Some expand the 5R to a 6R model. I have found it prudent to include a sixth R called the Reflect stage.
While most product development life cycles end at the Release stage, I believe it is important to add a phase where you reflect on the results of the deliverable, as shown in Figure 11-8. How well did it do once it was on the market? How many customers were willing to pay for the product? Was the deliverable satisfactory to customers? Is the product being used as advertised?
Figure 11-8. 6R model includes the Reflect stage
There are many types of feedback loops that can be used to gain an understanding of the product. This is why reflecting is very important in understanding the real value of the product. The feedback helps you determine how to adapt the idea for the future.
Most importantly, the Reflect stage ensures that you revisit the value placed on the idea in the Record and Reveal stages. Did you make the money you thought per what was written into the value or cost of delay of the idea? It is critical to the integrity of the R model that those involved understand that, once released, you will reflect on the idea and gauge its real value. While challenging the assumptions of value for an idea in the Reveal stage reduces gaming the value score, having to reflect on the actual value data once released can help further reduce any gamesmanship of the value data at the beginning.
Are Your Enterprise Ideas Visible?
The enterprise idea pipeline provides you with an end-to-end view of the flow of ideas from the moment they are recorded to when they are released. As an enterprise-level portfolio backlog of ideas, it is meant for the enterprise to respond to high-value ideas the moment they come so the enterprise does not miss the idea’s window of opportunity.
It is a more adaptable way of managing the portfolio of work across your enterprise and responding to feedback. Specifically, it is meant to highlight high-value ideas the moment they come into an enterprise so that they can be worked on almost immediately and the enterprise can take full advantage of the window of opportunity. Whatever you chose to call the enterprise idea pipeline, it holds the big ideas that will eventually (or immediately) be worked on by the teams. The enterprise idea pipeline is the parent to all of the product backlogs and helps you connect ideas to user stories.
The operation of the enterprise idea pipeline feeds right into your enterprise Agile budgeting and investment process. It can help you see where your high-value work is. You can learn more about effective Agile and continuous budgeting in Chapter 19.
For additional material, I suggest the following:
Lifecycles Are Good, an Idea Management Model is Best by Andrew Husak, Emergn Limited, 2016
User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton, O’Reilly Media, 2014