Enterprise Agility-The Big Picture (7): Vision and Release Backlog

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 and the Release. In this post, we’ll discuss two closely related topics, the Vision and Release Backlog, [callout (7] below.

big-picture-7-vision-and-release-backlog

The Big Picture 7-Vision and Release Backlog

The Agile Vision

In agile, the traditional product requirements documents (PRD), system specification, software requirements specifications (SRS) and the like are typically eliminated. In their place, agile enterprises take a leaner approach better suited to the last-responsible-moment, delayed decision making and artifact-light development practices of the agile enterprise. However, since the PRD and SRS documents no longer exist to specify system behavior, communicating the Vision for the product or system to the development teams becomes even more critical. Doing so is management’s responsibility, because no matter how empowered and energized the agile teams may have become, it is management’s responsibility to set strategic direction. In our Big Picture model, management delivers the vision to the team face-to-face in the periodic Release Planning events.

The Vision answers big questions for the system, application or product under development, including

  • Where are we headed with this thing?
  • What problem does it solve?
  • What features and benefits does it provide?
  • For whom does it provide it?
  • What performance, reliability, etc. does it deliver?
  • What platforms, standards, applications, etc. will it support?

In addition, the enterprise is too large to assume that all the global development teams will natively understand the various constraints and “ilities”, such as reliability, accuracy, performance, quality, etc, that are imposed on the system, so these must be communicated as well. These nonfunctional (example: performance) and common requirements (example: accessibility standards, common technologies) must be communicated and documented in a central repository where all teams can readily access them. They are an adjunct to the Vision and are every bit as critical. Your practices may be lightweight and agile, but the system still has to work.

An Agile Vision Can Take Many Forms

I’ve seen agile teams take a variety of approaches to communicating the Vision. (Note: I covered many of these in more detail in Chapter 17 of SSA– Lean requirements at Scale: Vision, Roadmap and Just-in-Time Elaboration).These include:

Note: It doesn’t even have to be that structured

In the last release planning session I facilitated, there wasn’t an opportunity for the four product mangers to collaborate prior to the release planning session. Even if there were, it’s doubtful that they could have necessarily come up with a harmonized, force-ranked feature set anyway. (Question: which product manager wanted their number one feature to be placed fourth on the release backlog?). Instead, we allowed each product manager approximately 45 minutes on stage. Their format was regularized as follows: 10 minutes context, 10 minutes vision and 20 minutes describing feature priorities. Each presented a briefing deck, which had a list and description of the top 10 features from their perspective. This was then provided as a handout to the team. Based on this context, the teams then went into the more detailed planning session.

Clearly, this was not the forced-rank prioritization we like to see in agile and it was up to the teams to decide what to do about the fact that four product managers each had separate priorities. But software, like life, can be a little messy. Most importantly, this model seemed to work really well, in part because the Product Managers were part of the process and they had compete visibility into what the teams could and could not achieve in the time box.

The Prime Content of the Vision Document is a Set of Features

No matter the form, the prime content of the vision document is a prioritized set of features. In my earlier book Managing Software Requirements (perhaps attaining agile wisdom means we don’t have to throw out everything we learned prior), I described features as “services provided by the system that fulfill a user need”. Features are “Big Picture” system behaviors that can be described in a sentence or two and which are written so that customers can actually understand, debate and prioritize them. In Managing Software Requirements, I posited that by managing the level of abstraction, a system of arbitrary complexity (from the space shuttle to the spellchecker on this editor) can be described in a list of 25 or so features. That still works for agile teams describing a Vision today and features can still be used as the primary placeholder for user value.

(Note: in many agile environments, the concept of the feature is sometimes replaced by the word “epic”, meaning “bigger than an iteration”. However, I find the word feature to be in more common usage, more consistent with prior practices and more natural to the stakeholders and their clients. It also has a natural correlation to agile feature teams which do the work of implementation. However, there is no standard usage model. Also, I’ve reserved the word “epic” in the Big Picture for the next higher, portfolio level.)

Undelivered Features Fill the Release Backlog

We introduced the Release Backlog in a prior post. In a manner similar to the Iteration (story) backlog which contains stories, the Release Backlog contains the prioritized set of features that have not yet been implemented. Like stories, features can be scheduled (in a release) or unscheduled (waiting for future attention). They are prioritized and estimated. Estimates at this scale are coarse grained and imprecise. For example, if teams use ideal developer days for stories (1, 2, 4, 8 etc), then features could easily be 10-50x that number. Better, at this coarse level, features might be sized solely on a relative scale (this feature is 2X bigger than that other one we just completed) and this prevents any temptation to over-invest in feature elaboration and estimating. If and when a feature reaches a priority such that it hits a release planning boundary, it will be broken into user stories as those are the estimation and implementation “currency” for the agile teams.

Note: Cohn and others often refer to this backlog as the “Product Backlog”.

On Decoupling the Tooling and Management Practices of Agile Features and Stories

Because of their fewer numbers of objects and higher level of abstraction, tooling and managing a release backlog composed of features (Level 2 on the  Big Picture)  is not quite as demanding as managing the team’s iteration backlog with stories and tasks (think thousands of user stories over time). In some reasonably agile large enterprises, I have seen the Release Backlog continue to be maintained in a traditional requirements management tool such as Doors or RequisitePro. While this may trigger a gag reflex in some agile circles, in my experience, the decoupling of features from the story breakdown through release planning means that the processes and tooling for maintaining these backlogs need not be the same, at least initially.

Moreover, some agile transformation agents have discovered that attempting to undo all the requirements practices of large, traditional enterprises could actually slow down the effective agile transformation for the development teams. Dev team progress can be stalled as the company debates these Level 2&3, guttural change initiatives. Allowing the Product Managers and Business Analysts to continue to use their existing tooling can therefore provide a much needed degree of flexibility. The wholesale replacement of a company’s Level 2&3 practices for requirements discovery, prioritization and tooling is therefore not a battle that must be fought immediately.

Of course, in the end it will be easier to have all the agile requirements objects (epics, features, stories and tasks) in a single, scalable agile project management tool such as Rally Software or Version One. This new class of agile requirements/agile project management tooling also allows assignment of the agile requirements objects to iterations and releases and provides for the ability to track feature completion across releases and teams via rollup reporting mechanisms. This can be a critical element in helping large numbers of teams deliver complex systems in an agile manner. Also, these new tools are starting to provide support for market-based prioritization, collaborative, on-line collection of user requirements, integration with the help desk and more advanced portfolio management features, so it is likely they will eventually take up residence in the portfolio planning offices (Level 3) as well.

For now however, when it comes to change management challenges of the substantive enterprise, the agile transformation specialist is advised to pick his or her battles carefully!

5 thoughts on “Enterprise Agility-The Big Picture (7): Vision and Release Backlog

  1. Fantastic post! The key thing we have learned about the vision and release backlog process is that it’s the primary mechanism by which large scale development efforts remain cohesive in terms of feature sets and prioritization.

    The larger your effort and the more complex your system, the more important vision and release backlog processes become. If you have a large agile release train – let’s say 10 teams, that focuses on an integrated solution, you have to manage the entire effort as if it was one effort. Otherwise, you will end up with a solution that doesn’t work well together

    Agile is about enabling small teams to be autonomous and highly effective. If you leave a team by itself to execute independently effectively, they will do just that! A solid vision and roadmap that depicts the entire solution helps product owners coordinate with each other in order to create a more cohesive solution.

    In addition, it also forces the enabling of a single product manager that owns all priorities. At the end of the day, all product managers must be aligned behind one vision so that the product owners they work with get unified direction

    For us, we rolled out agile before we had a firm vision in place. In addition, the complexity of our system forced us to take longer than we hoped to define that vision. In the meantime, product managers and product owners were living the vida loco cranking feature after feature as they saw fit. It was an amazing thing until we had were forced to have priority discussions that came to head with us rolling out the 2nd initiative of our vision. When we did, several product managers grew frustrated and fought back because their initiative wasn’t done yet.

    We had to retreat and redefine the 1st initiative in a way that all product managers agreed. We had to get leadership to designate one product manager as the overall leader of product direction. Finally, we had to significantly change expectations on our roadmap because the 2nd initiative could no longer be delivered in the timeframes we felt were necessary.

    Morale of the story? Take your vision, release backlog and release planning seriously. Realize it enables great cohesion and coordination. Realize it also ferrets out major issues like the ones I just mentioned!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s