Agile-Lean requirements position statement
0 likes855 views
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.
Agile-Lean requirements position statement
- 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