Agile Enterprise Requirements Information Model (6b) – Subset for Portfolio Management: Epics

Note: This is the next in a series of posts describing, in more rigorous terms, A Lean, Scalable Requirements Information Model for the Agile Enterprise (AE RIM) that underlies the Big Picture Series. In this series, I’ve been collaborating with Juha-Markus Aalto, Director of Operational Development for Nokia S60 Software Unit, where a variant of the model is being developed and applied on a very large scale development project. In the last post, the Agile Requirements Information Model for Agile Portfolio: Strategic Product Themes, we initiated our discussion of the two model elements at the Portfolio Level – Strategic Product Themes and Epics, with a discussion of Strategic Product Themes. In this post, we’ll conclude this level with a discussion of Epics.

But first, for context, here’s an updated version of the Big picture with the Portfolio level highlighted:

capture-big-picture-portfolio1Agile Enterprise Big Picture with Portfolio Level Highlighted

And here’s a look at the basic form of the updated requirements information model, with the portfolio level requirements items highlighted.

Basic Requirements Information Model with Portfolio Elements Hihlighted

Basic Requirements Information Model with Portfolio Elements Highlighted


Epics represent the highest level expression of a customer need as this (more obviously hierarchical) graphic shows.


Derived from the portfolio of Strategic Product Themes, Epics are development initiatives that are intended to deliver the value of the theme and are identified, prioritized, estimated and maintained in the Epic Backlog. Prior to release planning, Epics are decomposed into specific Features, which in turn, drive Release Planning in the Big Picture.

Release Planning in the Big Picture

Release Planning in the Big Picture

Epics may be expressed in bullet form, as a sentence or two, in video, prototype, or indeed in any form of expression suitable to express the intent of the product initiative. (I was in recently in a meeting where an (otherwise) clever agilist, pushing back on what he considered to be delaying and excessive epic-level documentation requirements, told his PMO management “you can even tell us in interpretive dance – we’ll take it from there”. Note, however, that this is not the recommended selling approach!)

With Epics, clearly, the objective is Vision, not specificity. In other words, the Epic need only be described in detail sufficient to initiate a further discussion about what types of Features an Epic implies.

Epics, Features and Stories, Oh My!

It’s apparent by now that Epics, Features and Stories are all forms of expressing user need and (hopefully) benefit, but at different levels of abstraction. Since this might be a less-than-satisfactory discriminator for the technical types, let’s look at an example.

In the Strategic Product Theme post, we hypothesized that past Strategic Product Themes for Gmail might have included: (by the way, I have no insights or contacts at Google; I’m just making this example up from their published information)

  1. Voice and video chat from within gmail
  2. Outlook integration
  3. Personalization
  4. Mail for Mobile
  5. Group chat

One can also imagine that Personalization of a user’s Gmail desktop is a significant initiative – one that Google might hope would create a strategic differentiation with Yahoo, Outlook and others – and one that could evolve over years. In other words, Personalization is a reasonable example of a well-stated Strategic Product Theme – you get the general idea, but you have no idea what exactly to do next!

In order to communicate better what to do next, prospective Epics, such as “Emoticons” and “User Background Desktop Themes“, could have then been identified, Then, the teams responsible for “User Background Desktop Themes” might well have brainstormed a multiple-stage implementation process, with the first releasable Feature being “apply a standard theme from Gmail theme catalog“, followed by “Allow users to further customize a chosen standard theme“. In the first iteration, the teams might have decided to create Stories to refactor the existing code. For example: “implement a framework where selected themes could be cataloged, selected and applied” and also a user value story “as an alpha tester, I can select and apply the first, prototype standard desktop theme so that I can provide early feedback on the concept”.

If this were the case, then the requirements information model for this example would be.


Requirement Hierarchy Example

Discriminating Epics, Features, and Stories

Still, we admit that there is no scientific way to determine whether a “thing you know you want to do” is an Epic, Feature or Story, but perhaps the following table of discriminators will help:


Type of Information Description Responsibility Time frame & Sizing Expression format Testable
Strategic Product Theme BIG, hairy, audacious, game changing, initiatives.
Differentiating, and providing competitive advantage.
Portfolio fiduciaries Span strategic planning horizon, 12-18+ months.
Not sized, controlled by percentage investment
Any: text, prototype, PPT, video, conversation No
Epic Bold, Impactful, marketable differentiators Program and product management, business analysts, business unit managers 6-12 months.
Sized in points.
Most any, including prototype, mockup, declarative form or user story canonical form No
Feature Short, descriptive, value delivery and benefit oriented statement. Customer and marketing understandable. Product Manager and Product Owner. Fits in an internal release (PSI) , divide into incremental sub- features as necessary.
Sized in points.
Declarative form or user story canonical form.
May be elaborated with system use cases.
Story Small atomic. Fit for team and detailed user understanding Product Owner and Team. Fits in a single iteration.
Sized in story points.
User story canonical form Yes

We also note in this table that Epics are indeed estimable (sizable). I covered that topic in an earlier, Big Picture post: Enterprise Agility – The Big Picture (13 continued): Estimating Epics.

Types of Epics

In earlier versions of the model and in the Big Picture we have indicated that there are two primary type of Epics to be considered:

Epics in the Big Picture and in the Model

Epics in the Big Picture and in the Model

  1. User Epics (Consumer Epics for many enterprises and earlier versions of the model) reflect those initiates that directly affect the deliver benefits to the end user.
  2. Technology (Architecture in earlier versions of the model) Epics reflect those initiatives that are necessary to adopt new technologies, or major architectural refactors that are necessary to create the architectural runway an enterprise needs to avoid excessive refactoring.

In our Gmail example, Personalization represents a User (Consumer) Epic. Perhaps an Epic such as “Ajax-enable across all supported browsers” could represent a significant Technology Epic.

Looking Ahead

Now that we have described Epics, we’ve introduced and elaborated on all the current model elements of A Lean, Scalable Requirements Information Model for the Agile Enterprise, Highlights (well, if you could call them that…) include the User Story and Acceptance Tests covered in the Agile Enterprise Requirements Information Model – Subset for Agile Project Teams, Features covered in Agile Requirements Information Model (4) – Subset For Agile Programs (a): Features and Feature Backlog, Nonfunctional Requirements (Backlog Constraints) and System Validation Tests covered in Agile Requirements Information Model (5) – For Agile Programs (b): Nonfunctional Requirements, Strategic Product Themes covered in Agile Enterprise Requirements Information Model (6a) – Subset for Portfolio Management: Strategic Product Themes

In a near term post, I’m going to recap the changes to the model in an updated graphic which recasts the Basic and Advanced forms of the information model.

Also, based on comments and feedback (like “whatever happened to use cases, can’t I use them in agile?), I also intend to discuss use cases in the context of agile development and this agile requirements information model. After all, if you are addressing enterprise class challenges, you may wish to have ALL the effective tools at your supposal. So I suspect I’ll be on this thread for a bit longer.

A Lean, Scalable Requirements Information Model for the Agile Enterprise

For those of you who have been following the Big Picture series, you may have noted that one element of the picture is the “requirements information model” that flows down the right side. This element of the model describes agile terms for expressing system behaviors at various levels of abstraction. (See below).

Big Picture with requirements model highlighted

The Big Picture, Highlighting the Requirements Model

In summary form, the model implies the following requirements-related elements and relationships as illustrated below.


For Big Picture purposes, this is an adequate explanation which helps the enterprise to understand the new labels for “requirement like things” in enterprise agile methods and the way teams use these new things to describe intended system behavior.

However, while the Big Picture supports “hand waving” descriptions of this complex problem, it does not define the exact nature of each element nor the critical relationships between them. For this purpose, my colleague, Juha-Markus Aalto, Director of Operational Development for Nokia S60 Software Unit, and I have been working on a semantic meta-model for agile enterprise requirements information management. The model also serves as the technical underpinnings for the requirements elements of the Big Picture. The need for the more definitive model is driven by two factors:

  1. The need for clear definition of each artifact type, so teams can be coached as how to use the appropriate element (ex: feature, user story, task) at the appropriate time
  2. The need to make explicit the relationships amongst the elements of the model (user stories, acceptance tests, features, etc.) to support tooling automation, which will provide enterprise- level support for status reporting and portfolio estimating and planning.

Last week, Juha-Markus presented this model at Object Days at the Tampere, Finland, University of Technology. His full presentation can be found here.

Lessons Learned at (truly) Enterprise Scale Agile Adoption

The purpose of Juha-Markus presentation was not the model itself; rather it was to describe how this model supports the enterprise level agile practices being deployed in the development of Nokia’s S60 Software Platform and Applications. Nokia’s S60 Platform is a software platform for mobile phones that is currently amongst the leading smart phone platforms in the world. The Platform is built by an extensive network of software teams who are applying Scrum to increase the productivity and quality of their local efforts. S60 in turn, is built on top of the Symbian OS, further coupling the efforts of the Nokia development teams to the many software practitioners of this critical supplier. Nokia S60 teams’ experiences in scaling agile across a large number of intensively collaborative software teams represents some of the most advanced agile thinking and practices, at the greatest scale, of any that I am aware of.

These experiences serve as an excellent object lesson for others in (really) Scaling Software Agility. For more on this topic, I refer you to Juha-Markus’ presentation which will provide a fuller understanding of some of the challenges the S60 teams are addressing with their new agile model.

The Requirements Information Model

The purpose of this post, however, is to introduce the requirements information model that we have been collaborating on. The most basic form of this model (more in future posts), as represented in UML form, is shown below.

A Lean, Scalable Requirements Information Model

A Lean, Scalable Requirements Information Model

When compared to the Big Picture, it’s obvious that the Big Picture graphic is an oversimplification of the reality of large scale, agile system development. While the elements of Epic, Feature, Story, Task and Backlog are described in the Big Picture and elaborated in supportive posts, the elements of Strategic Product Theme and Acceptance Test have not. These are described below:

  • Strategic Product Theme – this information model adds this, new and highest level element to the information hierarchy. Themes provide a well-defined set of core value propositions that in turn, drive portfolio investment. They define the key strengths of the enterprise, deliver on strategic initiatives and solutions, and drive long-term competitiveness. Themes, in turn cause the creation of Epics, Features, and Stories that deliver on the themes value proposition. (In the Big Picture, Themes can be considered to be the various “slices” in the portfolio management pie chart at the upper left)
  • Acceptance Test – moving all the way to the bottom of the stack, the model also highlights the critical role of the acceptance test in agile development. In turn, this encapsulates two key agile quality principles: 1) there is always at least one acceptance test for every story (in agile, all code is tested code) and b) a Story cannot be considered “done” until it passes the test.

Lastly, the Non-Functional Requirement is a primary element in this model, which reflects the role these special requirements play in the development of enterprise class systems. (These were called out as auxiliary elements of the “Vision + in the Big Picture.)


That summarizes the primary elements of the lean, scalable, requirements information model. To the new or smaller team Agilist, this model may seem relatively complex and perhaps not very agile, or at least not “the simplest thing that can possibly work”. However, experience has shown that thinking about the solution space in these varying levels of abstraction is in fact, a simplification of the problem at enterprise scale and encourages agile thinking throughout the organizational hierarchy. I’ll describe why in an upcoming post.

Enterprise Agility – The Big Picture (14b): More on Agile Portfolio Management and the Legacy Mindset

Note: This is part of a continuing series (see the Big Picture Category on this blog) wherein we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In a series of continuing posts, we have been working our way from the bottom (stories, iterations and the like) to the top where the enterprise vision and portfolio management resides. This post is one in a miniseries describing the last big icon on the upper left – Agile Portfolio Management.

The Big Picture - Agile Portfolio Management

The Big Picture - Agile Portfolio Management

In the last Big Picture Post, we introduced the portfolio, along with the challenges that agile teams are likely to find as the impact of their new and more productive models wends its way to the Project Management Office (PMO), which in some cases can be the “mother ship of potential agile impediments.” We also introduced the excellent DTE energy case study: Establishing an Agile Portfolio to Align IT Investments with Business Needs. This case study is an example of how an agile enterprise can first recognize, and then successfully address the significant changes necessary to allow the emergence of true enterprise agility benefits.

Since that post, I’ve been thinking that I would expound on the legacy mindsets that called out in the case study. But I’ve decided I can’t. They are just too well done and so symptomatic that I decided just to repeat them here. However, the accompanying descriptions and paraphrasing are my own. These are based on my own experience from two perspectives; 1) then, as an executive, managing portfolios and carrying some elements of these mindsets, and 2) now, as an agile executive attempting to change those very same mindsets!

The legacy mindsets called out in the DTC case study are:

  • Widget engineering – The belief that software development is a repetitive, controlled and manufacturing-like business, rather than Research and Development. “Draw it up and build it like you drew it,” goes the thinking.
  • Order Taker Mentality – Also known as “build what we tell you to build”. Founded on the belief that the customer is always right, seemingly all-knowing and under the assumption that they actually know what their requirements really are. The teams should just build it.
  • Maximize utilization- The belief that if all resources aren’t fully utilized on paper then they won’t be fully utilized in practice. “They’ll just be idlers, wasting their time, waiting for their next assignment.” goes the thinking. “Fully assign them or lose them”.
  • Control through data – The belief that
    with the right kind of data – earned value metrics, design reviews, requirements and test plan inspections – we can tell where we are on the project. And then if we still can’t tell where we are, we’ll just ask for more detailed data until we can.
  • And we can plan out a full year of projects- Conveniently disregarding our last 20 years or so of experience in failing to predict projects a year in advance, we assume it’s a failure of our planning, not a failure of the basic paradigm. “If we only planned in more detail, we could really get it right this year.”
  • Get it Done – The belief that our best case plans can be reality if we only try hard enough.
    Also known as: “That was the plan we agreed to, now execute it.” And “when the going gets tough, the tough get going”. And lastly, the infamous “we know it’s impossible, that’s why we hired you for this job.”

Perhaps it’s obvious from my elaborations that I tend to get somewhat passionate about this topic. Perhaps it’s because my guilt shows through. Surely, I have been on the other side of this fence before iterative and incremental, and now agile, development methods proved their extraordinary worth. So, I know as well as any that if these legacy mindsets are not addressed, they will kill the agile enterprise initiative as surely as a fixed content/fixed schedule 60 hr/week death march.

Here’s why. The table below shows the manifestation of these problems in practice (as described by DTE along with a few of my own) and the real problems they create for the nascent agile teams.

Mindset Manifestation Problems
“widget engineering”
Fixed schedule, functionality planning

Big Up Front Design/Analysis (BUFD)

Long range plans

Resources fully committed up to a year in advance

Analysis paralysis

“order taker mentality” Build what we tell you to build

We are the boss of you

False agreements. No buy in.

Misses innovation contribution from teams

Failure to meet expectations


No empowerment, lower motivation

“Maximize utilization” Resources committed long range

100% allocation before “what if”

Key resources assigned to multiple projects

No time to think or innovate

Dedicate resources to task or lose resources

Thrashing – lost productivity of most valuable resources

Exhaustion, burnout

“we can plan out a full year of projects” Detailed wbs, earned value metrics, fully loaded Gantt charts Plans are immediately obsolete, but not treated that way

Earned value metrics don’t reflect actual progress

“Control through data” Fine grain reporting and overhead

Milestones that are not reflective of process or progress

Reporting overhead slows actual development

Annoys and de-motivates the teams

“Get it done” Belief that best case plans must succeed Deferred recognition of plan vs. actual

Late discovery and re-negotiation

Loss of credibility, mistrust

You’ll probably recognize many of these mindsets, manifestations and the problems they create for the development teams. Many enterprises do. In one recent presentation I made highlighting the DTE case study, one PMO executive said “just delete DTE and put in [our company name here] and there you have it”!

Well enough crabbing and I’m sorry if I offended anybody. I just thought it important to walk through this pain field one last time, making sure we understand the problem so that the imperative for a solution is really, really apparent.

In the next post in this series, I promise to move to a more productive and proactive set of ideas to address these problems. One giant step further to actually becoming the agile enterprise.

Enterprise Agility-Big Picture (5): The Release Revisited

In the post, Enterprise Agility-The Big Picture (5): The Release, we described that seminal, value delivery construct of the Agile Release. (see Big Picture below).


Agile Big Picture - Internal vs external release?

But as with all the other oversimplifications in the Big Picture, (which at times seems to create almost as many questions as answers) comments and questions have been raised about what makes a Release a Release. In the book, I described the release on the agile release train in terms of an “internal release milestone” as opposed to a GA (General Availability) release.

The reasons for this are many and for further perspective, I refer you to Chapter 18: Systems of Systems and the Agile Release Train and Chapter 21, Impact on Customers and Operations. In Chapter 21, I described at length how attempting to synchronize the team’s internal development cadence with external release milestones is an over-constrained problem. Dates and features never line up to market events; public relations has an information cycle of its own; customers do not always want to adopt your new software at the rapid pace at which it now evolves, etc. etc. (see Chapter 21).

To address this problem, I suggested that the development teams build their own engineering cadence in a manner conducive to the most efficient development operations and build a GA firewall between the internal development cycle and the distribution model. This is illustrated in the picture below:

Agile Release Train GA Firewall

Agile Release Train GA Firewall

This creates a separation of concerns which allows entities on both sides of the firewall to do their best work without constraining each other.

In any case, with respect to the Big Picture, however, I Indicated the Release milestone is just a Release and that has created questions from readers. From a purist perspective, the release illustrated on this picture is really an Internal Release, which may or may not be a GA Release, (though I’ve decided not to update the picture for fear that would be more confusing to the casual observer). If the internal release is not a GA Release, then the question becomes, why even have it? The answer is that the internal release model is integral and seminal to the agile enterprise model:

  1. From a portfolio planning perspective, the internal release frequency is controlled by the teams to a timeframe that makes face-to-face, enterprise-level release planning feasible from a travel and cost overhead perspective. Re-planning happens at these boundaries and hopefully, only these boundaries.
  2. From a technical perspective, if  for whatever reason, it is difficult to assure true system level quality at iteration boundaries, then this milestone represent an absolutely Potentially Shippable Increment at the system level and it meets all the reliability, performance, standards compliance, and compatibility that is required for a GA release. Its fast, it’s frequent, it is of high quality and it is available!
  3. From a human resource perspective, teams perform best when they work together long enough to be in the flow (the performing phase of the Forming – Storming – Norming – Performing model
    of group development) and that typically takes a release cycle or two, so the release boundaries
    are the best times to adjust teams to address the current bottlenecks in value delivery. This provides teams with the stability they need for high performance, while simultaneously giving the enterprise the resource flexibility it needs to achieve agility.

Hopefully, this clarifies some of the questions and comments on the Big Picture Release. Continue reading

Enterprise Agility-The Big Picture (12): Architectural Runway

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed Agile Development Teams, Agile System Teams, Iterations , Agile Product Owner, Backlog, User Stories and the Iteration Backlog , Release , Vision and Release Backlog , The Roadmap, Agile Product Manager, and the Release Management Team. In this post we’ll describe Architecture Runway [callout 12] below.


Big Picture 12-Architectural Runway

For any familiar with this blog or my book (Chapter16 of SSA – Intentional Architecture), the topic of agile, intentional architecture is not a new topic. The blog series on this topic is here. A whitepaper in this topic, Principles of Agile Architecture: Intentional Architecture in Enterprise-Class Systems, coauthored by myself, Ryan martens and Mauricio Zamora can be found here. Also, I recently presented a Rally webinar on this topic and you can see that webinar here.

In Scaling Software Agility, I defined architectural runway as:

A system that has architectural runway contains existing or planned infrastructure sufficient to allow incorporation of current and near term anticipated requirements without excessive refactoring.

Continuous build out and maintenance of new architectural runway is the responsibility of all mature agile teams. Failing to do so will call cause one of two things to happen, either of which is very bad:

  1. Release dates will be missed as large scale, just-in-time, in-situ infrastructure refactoring adds substantial risk to scheduling
  2. Failure to address the problem systemically means that the teams will eventually run out of runway. New features cannot be added and the system becomes so brittle and unstable that it has to be rewritten from the ground up.

Architecture in the Big Picture

With respect to the Big Picture, Intentional Architecture appears as a “red thread” through various levels of the hierarchy.

  • Level 3 – At Level 3, Architectural Runway is represented by Infrastructure initiatives that have the same level of importance as the larger scale requirements epics that drive the company’s vision forward. While many architectural initiatives will be addressed routinely by the teams over time, others require elevation to the portfolio level to assure awareness and communication of these important initiatives. They will consume substantive resources and failing to implement them will compromise the company’s position in the market. They must be visible, estimated and planned just like any other epic.
  • Level 2 – At Level 2, Product Managers, System Teams and other stakeholders translate the architectural epics into features that are relevant to each release. They are prioritized, estimated and resourced like any other feature. At each release boundary, each architectural initiative must also be conceptually complete, so as to not compromise the new release, though it may or may not surface itself to the user.
  • Level 1- At level 1, refactors, design spikes, evaluations etc. that are necessary to extend the runway are simply a type of story that is prioritized like any other story. Architectural work is visible, accountable and demonstrable at every iteration boundary. This is accomplished by agreement and collaboration with the system architects (Level 2) and agile team and tech leads (Level 1) who determine what spikes need to happen when, and who work with the Product Owner to prioritize the iteration backlog. (see picture below).

    Architecture is a role collaboration

    Architecture is a role collaboration

In this manner, architecture is a first class citizen of the Big Picture and is a routine portfolio investment consideration for the Agile Enterprise.

In the next Post, we’ll elaborate on the Agile Portfolio Vision.

Enterprise Agility-The Big Picture (9): The Agile Product Manager

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed Teams, Iterations , the Agile Product Owner, Backlog, User Stories and the Iteration Backlog the Release , Vision and Release Backlog and The Roadmap. In this post, we’ll discuss the Agile Product Manager, [callout 9] below.

Big Picture 9 - Agile Product Manager

Big Picture 9 - Agile Product Manager

I’ve blogged off and on the “agile product manager vs. agile product owner” roles over the last few months so this is not a new topic and I won’t repeat it all here. Many of these posts are categorized under the Product owner/Product Manager category on this blog. We have also touched on the Product Manager in the Big Picture post on the Agile Product Owner and the follow on post. In addition, I described some of the basic Product Manager responsibilities in this article a few years back.

Based on blog hits and search criteria, this topic is pretty relevant right now so it’s a good time to elaborate further on the responsibilities of this role within the context of the Big Picture.

Product Manager/Business Owner/Business Analyst?

Throughout this series, I’ve used the term “Product Manager” instead of Business Owner or Business Analyst, even though those terms may be more familiar in some enterprises. Regardless of organizational structure or title, an effective business owner must exist and they must drive the vision either directly, or through the product management/business analyst organization. An effective Business Owner/Product Manager should exist for each major domain of the solution or the agile teams will be filling in the gaps, possibly with mixed results, depending on their expertise in the various domains. For consistency, we’ll continue to use the term “Product Manager” from here forward, but the reader may wish to translate that into the terms of their enterprise.

Responsibilities of the Product Manager

Agile or not, the Product Manager must fulfill the following responsibilities:

  1. Stay abreast of the latest industry trends
  2. Understand the changing needs of the market and the customer base
  3. Maintain a solid understanding of the current solution

Using this data, the Product Manager’s primary responsibility is to then

  1. Articulate a clear direction for addressing gaps and opportunities

The Agile Product Manager

Like most every other role in the software enterprise, the Product Manager’s role evolves as the company transitions to agile development methods. The first decision is whether or not the Product Manager assumes the role of the agile Product Owner and thereby takes on the additional responsibilities for iteration planning, story elaboration and prioritization, demo and acceptance. As we’ve noted before, that is probably not practical within the enterprise (see Responsibilities of the Agile Product Owner vs. Enterprise Product Manager and Role of the Product manager ). The differing responsibilities for the two roles are then as highlighted in the following table.

Agile Product Manager and Agile Product Owner

Responsibilities: Agile Product Manager and Agile Product Owner

Agile Product Manager in the Big Picture

As can be seen in the table and as is implied in the Big Picture, we see that the Product Manager owns the Vision and Release (Feature) Backlog and as its implementation in the Release and the
Roadmap. The Product Owner is a charter member of the Agile Team, and owns the User Stories and Iteration (story) Backlog and the implementation via Iterations. Working together, the Product Manager and Product Owner steer the agile enterprise.

To fulfill these responsibilities, the Agile Product Manager:

Owns the Vision – in collaboration with the business owners and the Product Owners, the Product Manager sets the Vision and the prioritized feature set which further describe how the Vision may be fulfilled in the implementation.

Drives the Release Objectives and Priorities through Release Planning – The Product Manager plays a key role in the Release Planning process as well, whereby they have routine and periodic, face-to-face opportunities to communicate objectives directly to the agile teams.

Updates and Maintains the Roadmap – One result of this process is the Product Roadmap, which serves as the plan of record for coupling the Vision to Implementation Timelines. The Product Manager uses the Roadmap to communicate the Product Managers “big picture” to the stakeholders inside and outside the enterprise.

That’s it for the Agile Product Manager. In the next post in the Big Picture Series, we’ll get back to the execution model and describe the role that the Release Management Team plays in helping assure the successful implementation of all that Vision.

Note: A Special thanks to Mauricio Zamora of CSG systems, who contributed some content and insight for this post.

Enterprise Agility-The Big Picture (8): The Roadmap

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed Teams Iterations , the Agile Product Owner, Backlog, User Stories and the Iteration Backlog the Release and Vision and Release Backlog. In this post, we’ll discuss the Roadmap, [callout 8] below.


The Big Picture 8-The Roadmap

For anyone following this series closely, you may have noticed a subtle shift at some point when the Roadmap icon (8) magically appeared behind the Vision (7). While I’ve been trying not to overload the Big Picture with unnecessary detail, it became clear during my explanations that the Roadmap is integral to the Big Picture and you can’t effectively explain enterprise agility without describing this key element.

When we described the Vision in the last blog post, it was presented as time-independent; the Vision is intended to provide a sense of the objectives of the product or system without any binding to time. This is appropriate as the objective is to communicate the gestalt of “what this thing is we are about to build” and overloading with timelines will likely derail the discussion of the “what”.

However, in order to set priorities and plan for implementation, we need an additional perspective that enhances the understanding. This is the purpose of the Roadmap. The Roadmap is not a particularly complicated thing, nor is the mechanical maintenance of it difficult. For example, a typical Roadmap might be communicated in a single graphic as follows:

Sample Product Roadmap

Sample Product Roadmap

The Roadmap consists of a series of planned release dates, each of which has a theme and a prioritized feature set. While it is a simple thing mechanically to represent the Roadmap, figuring out the content is another matter entirely. The topic of what the team plans to ship and when can be a deep, fascinating and occasionally contentious topic in agile and we can’t cover it all here. However, the easiest way to think about the Roadmap is that it is an output, rather than an input to the Release Planning process. Fortunately, we covered Release Planning fairly extensively in the Release Planning blog series as well as in the Enterprise Agility Big Picture (6) The Release so there is some Roadmap guidance there for those who follow this Big Picture model.

But before you do all that clicking and reading, here are some summary guidelines for the role of the Roadmap in the context of the Pig Picture:

  • The Roadmap is an output, rather than an input to the Release Planning Process
  • The next release may be Internal or External. In either case, the dates and themes for the next release are fixed. The features are prioritized and variable.
  • The Roadmap is a “plan of record” and is subject to change as development facts and customer needs change
  • The teams generally commit to only the features in the next upcoming release. Releases beyond the next represent only the team’s current best estimate.

And perhaps the most important guidance is this:

  • Even within the next upcoming release and even though the team has committed to the objectives of the release, the feature set cannot be guaranteed. If it were, then you would have fixed scope-fixed time-fixed resources for an extended time period and that fails the agile acid test. However, it is a reasonable expectation that a team that has committed to the release will:
    1) meet the date
    2) meet the theme or objective, and
    3) deliver most of the features, and certainly the highest priority ones with the requisite quality.

    Doing anything less would be unprofessional and belie the power, discipline and accountability of our agile enterprise model. Moreover, it will eventually threaten our own empowerment, as failure to deliver will inevitably cause the implementation of various controls to “help us”!

That’s it for the Roadmap in the Big Picture. We’ll touch upon it again in our next post, the Agile Product Manager.

More on the Big Picture (3)- Product Owner vs. Product Manager

In the post Enterprise Agility–The Big Picture (3): Role of the Product Owner, I discussed the differences between the Product Owner and the Product Manager. In the past, I’ve discussed the fact that, at least in the larger enterprise, these are typically NOT the same individual and this is clear from the Big Picture Itself.


Big Picture 3- Product Owner and Product Manager

The reasons are straightforward. Simply, there are typically not enough Product Managers, nor are they necessarily inclined by training or interest to spend some/much/most of their time working directly with the product teams. The math itself is part of the problem. I’ve seen enterprises with up to 400 practitioners operating with as few as 4-6 Product Managers. It simply isn’t practical to assume that they will be able to support the Agile Manifesto Principle: Business people and developers must work together daily throughout the project. Even if they were so inclined, there simply aren’t enough hours in the day. And if they did spend most of their time with the teams, they become further removed from the customer the enterprise is required to serve. That can’t be good. (For more on this topic, check out the Product Owner/Product Manager category on this blog).

Moreover, the effective Product owner exhibits must exhibit a degree of technical competence in order to deserve and earn the respect of the team. As I noted previously,

“the foundation for effective decision making is driven by the technology of the implementation. In addition, continuous refactoring is integral to agile, and since the product owner owns the backlog, prioritizing refactors vs. value stories is a critical skill that requires a technical foundation.”

This blog post has raised some interesting comments which those interested in the topic may want to peruse at Enterprise Agility–The Big Picture (3): Role of the Product Owner.

One in-depth comment in particular, takes some issue with my recommendation (which I still support) that the Product Owner reports into the same line management as the team. To save you time, I’ve incorporated some of those comments from Malamo below:

“I want to expand a bit on the concept of trust. Agile forces a very interesting and powerful change with the Product Mgt and Development relationship. For years, it’s always been the same story – PM asks for too much and Development delivers too little. It’s been a conflict since the beginning of time and it’s always the other person’s fault. For the context of this post, I am going to declare one big assumption: that the product owner is properly skilled and has all the leadership characteristics listed above. The one I will add is that they should be a natural leader – more than anyone else, I believe the product is the person most responsible for keeping the team focused, motivated and engaged.

A good product owner changes the conflict mentioned above – completely. Their alliance is with the team and as a result, the conflict switches from PM vs. Development to PM vs. PO. The PO is the person responsible for ensuring product management is happy with the results. I have seen numerous situations where the PO has passionately defended the team’s performance. It’s a wonderful thing…

The product owner is also responsible for fostering and maintaining a solid relationship with the PM. If this doesn’t happen, it will create significant issues because ultimately the true stakeholders will start to question the ability for agile to deliver better results. The PO becomes the bridge between PM and Development. The PO understands with specificity what it takes to develop SW.

As a result of this shift in conflict, I personally believe all POs should report under the Product Management organization and NOT under development. Nothing changes from what Dean posts above – it’s all still critical. The PO should be collocated. The PO’s alliance is with the team. However, the dotted line (or direct line) relationship to the PM creates a needed balance of power.”

Enterprise Agility-The Big Picture (6): The Release

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed Teams, Iterations , the Agile Product Owner,  types of Backlog and User Stories and the Iteration Backlog. In this post, we’ll discuss the purpose of this entire endeavor, the Release. [callout (6)]


Big Picture 6-The Release

In the last few posts, we’ve described how agile teams cooperate to produce increments of software in iterations. While the goal of each iteration is to produce a “potentially shippable increment” of software, teams-especially larger-scale enterprise teams-find that this is a “tall order” and it may simply not be practical to achieve a shippable increment at each iteration boundary.

Not Every Iteration Can or Should be Released

There are a number of internal, technical reasons as to why an iteration may not be releasable:

  • Accumulation of technical debt (needed refactors, test automation, accumulated defects). No iteration is perfect and even good teams often build up some technical debt
  • Need to create specialty documentation and certifications that may not be practical or economical at each iteration
  • Need to test the application across the “matrix of death”, i.e. compatibility checking for the hundreds of variants that are likely necessary to cover all platforms, devices, interfaces etc
  • Need for more extensive performance, reliability or compliance testing,  for which the tools and resources may not be available or practical for each team

These are some of the reasons we have included a hardening iteration in our Big Picture model.

Moreover, there are good business reasons why not every increment, even if it were potentially shippable, should be shipped to the external customer:

  • Potential for interference with a customer’s existing purchasing contracts and support agreements
  • Potential for customer overhead for user training
  • Potential for disrupting customer’s existing installation

This is the reason many agilists have recommended the Two Levels of Planning and Tracking as I described in Chapter 10 of SSA. (Note: XP explicitly calls out the Release and Iteration pattern. Scrum, per se, has only the single Sprint construct, but in practice many Scrum teams have evolved a model of releases following a Sprint-Sprint-Sprint-Release Sprint (hardening Sprint) pattern, so I don’t think there is much debate in the agile community about this basic two-level construct).

A Release can be Internal or External

In Chapter 18-Systems of Systems and the Agile Release Train and Chapter 21-Impact on Customers and Operations, I described a number of constructs and constraints that cause teams to focus more on a continuous stream of Internal releases (truly potentially shippable increments) than External Releases (General Availability- release to market, upgrade install base, push to distribution, etc.). This focuses the team on things they can control – including fixed internal release dates, quality criteria, etc.- rather than what they cannot control – timing of announcements and PR, impact on install base, fixed trade show deadlines and the like. This may best be illustrated by the “firewall” construct in the following graphic:

Firewall between Internal Releases and GA

Firewall between Internal Releases and GA

So while the Big Picture labels it simply as a “Release”, it is with the understanding that the release can be either Internal or External and the general cadence is driven by a periodic and fixed Internal Release calendar.

Releases are Driven by a Theme and Feature Content

Be it internal or external, all releases follow the same basic pattern. They are driven by a Theme or Set of Objectives, a label that clearly communicates the business objective of the release along with a prioritized feature backlog. In the same manner that stories are sized to fit in iterations, features are sized to fit in a release. This helps assure that each release is driven by a set of objectives that deliver holistic (even if modest and incremental) customer value. At release planning time, features are decomposed into stories. With appropriate automated tooling support, the status of features can be tracked via accumulated story completion.

Planning the Release is a Seminal Event in the Enterprise

I’ve blogged extensively about the criticality of period, face-to-face Release Planning events and I won’t repeat it here. But in any case, every release has a kickoff Release Planning session that the enterprise uses to set the company context and to align the teams to common business objectives for the release. The teams, in turn, plan the release and provide an estimate of the feature set that will be delivered in the release. This is the team’s commitment to the release, and they endeavor to meet their commitment by satisfying the primary objectives of the release, even if it turns out that not every feature makes the deadline.

We’ll describe how the release content is driven by a Vision and a prioritized feature set (the Release Backlog) in the next post.