The document discusses challenges with traditional requirements documentation approaches and presents an agile-lean alternative. It notes that traditional approaches assume complete understanding before development and risks not meeting customer needs. The agile-lean approach recognizes requirements evolve and advocates iterative development with minimum artifacts like a product vision, user stories, and prioritized backlog managed by business partners. The approach focuses on collaborative work between business partners and developers to continue learning requirements during the project through user stories.

1. 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
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”.
@Copyright 2010 – Russell Pannone. All rights reserved. Page 1

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.
@Copyright 2010 – Russell Pannone. All rights reserved. Page 2