The Challenge of Enterprise Requirements Management

were discovered and documented.

These integration "bugs" would not have been uncovered until analysis, which is typically when developers start looking at the requirements. Imagine the flow obstruction (Lean anti-pattern) that would result from tracking these "issues" to closure. It is no wonder software is often over-engineered and full of waste.

The Business Value Roadmap: How Index Cards Bring Structure to Business Vision

We've reviewed how two bridging efforts (requirements gathering specialists and use cases) can cause unintended outcomes and actually extend the chasm between Business and IT. So what is the answer? How can structure be brought into enterprise requirements management for product development or IT project efforts in a way that reduces time-to-market, keeps quality high, and increases organizational learning? The answer requires courage--courage to empower the enterprise organization with the ability to work in self-sufficient, highly collaborative units that are allowed to pull prioritized capabilities and implement based on the team's capacity.

This activity is led by a Business Value Roadmap, written in business terms and goals, which is detailed at the right time based on each team's capability to begin implementation. It presupposes that an Agile organization exists, and that top-down support is in place for removing dependencies from each Agile team. This prerequisite is not easy to achieve, but once the organization has scaled Agile methods to the point where multiple cross-functional teams are in place, the Business Value Roadmap can guide the enterprise and keep tight alignment with changing business needs.

The roadmap itself is easy to generate and manage. Capabilities called out in Project Charters and Statements-of-work can be prioritized and changed as rapidly as business goals dictate. These capabilities can be tracked as epics, which are defined to be high-level business goals and are typically broken into smaller features defined as user stories or more simply stories. In the Agile world, an accepted practice is to capture epics on white index cards, and stories on yellow index cards.

Mike Cohn defines a user story as information that "...describes functionality that will be valuable to either a user or purchaser of a system or software." [viii] It can be thought of as a small piece of functionality captured in business language that can be written on an index card with a permanent marker. The index card metaphor is valuable in that it limits the amount of detail that can be captured up front.

When detail is required, an cross-functional Agile team breaks the story down into small tasks, which are typically captured on blue index cards, along with an estimate. The key take-away is that the detail is not determined until it is required. The roadmap itself should keep visible Capabilities (captured by epics) that are tightly coupled with business goals.

An expected, reaction to capturing enterprise requirements on index cards is laughter. So much energy has been put into creating enterprise templates to capture Project Charters, Capability Matrices, Use Cases, Requirement Specifications (functional amp; non-functional), etc., that these artifacts will be defended by the organizations that creates and manages them. So how does one introduce Agile requirements in such an organization?

My recommended approach is to spend extra energy preserving the mapping between high-level capabilities and epics, and finding ways to map stories back to the enterprise documentation. This is a nice transition role for Business Systems Analysts looking to contribute on an Agile pilot. In the end, capturing ideas on index cards and placing them on a prominent wall gives visibility and line-of-sight to all work in progress. [ix]

Lean principles dictate that work-in-progress should be minimized in