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.
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:
- Draft Press Release
- The “Very Preliminary Data Sheet“
- Jim Highsmith’s “Product Vision Box“
- RUP-Like Vision Document. (One very agile team once told me, somewhat defensively, about why they still loved their RUP-derived Vision template: “We write to make sure management understands what we are about to build”)
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!