@Copyright 2010 – Russell Pannone. All rights reserved. Page 1

The significance of the Agile-Lean Requirements Position Statement is it defines the need, belief, and the readiness

to do what it takes to effectively write agile requirements and deliver commercial or operational value. The Agile-

Lean Requirements Position Statement ensures unanimity of purpose within the enterprise and the agile product

development and delivery teams by serving as a reference point, educational value and motivating force:

Reference Point

It guides by providing a common understanding of purpose.

Educational Value

It educates people about the common vision and purpose. When everyone is able to understand the overall

approach a kind of unity of purpose is achieved.

Motivating Force

It offers a roadmap to all team members. They draw meaning and direction from it. Targets are set, work is

committed to and team members can now compare themselves against the benchmark set by the Agile

Requirements Position Statement. They can unilaterally change direction whenever they go off the track and set

everything along right paths.

Another very important prerequisite to writing agile requirements is first putting stories in perspective of the overall

product development endeavor as depicted in Figure 1.0, looking both “upstream” and “downstream”.

Agile-Lean Requirements Position Statement

Challenge

The traditional approach is to attempt to document the requirements for the whole product and

then freeze the requirements to provide a stable base for development to proceed

Though this may work in some cases, it assumes that we can come to a complete understanding

of the product (system-software) before developing code

Perhaps this is possible in simple or well-known business domains but this is a risky assumption

to make for most system-software products high in risk and complexity

Tenets - Guiding Principles

We recognize and acknowledge the final product evolves during its development and we must

position ourselves to adapt to change

We realize trying to document all requirements and freezing requirements during early project

phases will either cause rework or the delivery of a product that does not meet the Customer

needs

The minimum key agile requirement artifacts are a Product Vision, User Stories and a prioritized

and sized Product Backlog; managed and owned by the Business Partner or Customer

Enactment – Make it So

Fundamentally, our approach is building product features iteratively and incrementally by

Business Partners and IT working collaboratively; built around a key assumption – we continue

to learn about the product during the project

Leveraging effective collaboration between who possess requisite knowledge, authority and

responsibility for the requirements, the Business Partner, and who possess the craftsmanship for

delivering on the requirements, the Development Team by writing stories

@Copyright 2010 – Russell Pannone. All rights reserved. Page 2

Figure 1.0 – Putting Stories and Agile Requirments in Context

Knowing what comes before the writing of stories and what comes after the writing of stories and who is going to

consume the stories sets the context for the form and substance of a story.

A story is a means to an end, to capture the Product Owner’s delineation of the product features (who, wants what,

why) and not the specifics of the solution or the details about “how” the team will implement the story.