Managing Requirements in an Agile World: Avoiding the Round Peg/Square Hole Dilemma

Transcription

1 Managing Requirements in an Agile World: Avoiding the Round Peg/Square Hole Dilemma Nancy Y. Nee, PMP, PMI-ACP, CSM, CBAP VP, Global Product Strategy, ESI International

2 Agenda Agile? SCRUM? What s the Difference? Agile In Practice 10/22/2012 ESI International, Inc

3 Here s what we ll cover Agile or SCRUM what s the difference? Agile Manifesto Is this just another fad? The 3 layers of agile requirements Backlogs, User Stories, and Acceptance Tests Agile Requirements

4 Method Agile Requirements

5 Frameworks & Methods Agile AGILE MANIFESTO Velocity Tracking Dynamic Systems Development Methods Extreme Programming Scrum Open Unified Process Essential Unified Process Feature Driven Development Agile Unified Process Agile Modeling Agile Requirements

6 Agile Manifesto 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer s competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity the art of maximizing the amount of work not done is essential. 11. The best architectures, requirements and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

7 Not just another fad perceived IT project success rates Iterative 12% 31% 67% Agile 12% 29% 61% Ad-Hoc 15% 40% 53% Traditional 18% 41% 52% Failed Challenged Successful Note: Accurate to within +/-7% Figures don t add to 100% due to use of ranged options Copyright 2010 Scott W. Ambler

8 Agile in Practice From the Top Down Portfolio Backlog The Portfolio Layer Architecture Investments Portfolio Management The Program Layer Features Product Backlog Releases Product Management The Team Layer Components Team Backlog Stories & Iterations Agile Teams

9 Requirements at the Portfolio Layer Highest Level Requirements Business Requirements are high-level needs, goals or objectives of an enterprise in its entirety ~ IIBA These types of requirements evolve out of enterprise analysis activities In the Agile world there are 2 types of high level requirements Investment Themes Epics

10 Investment Themes & Epics Investment Themes are bigger or more lofty than epics epics are decomposed themes Investment themes are a set of initiatives that drive investments, which in turn drives goods and services In Agile terms investment themes are established annually by the Portfolio Management Group Themes generally have a much longer shelf-life than epics

11 Investment Themes & Epics There are 4 flavors of Investment themes that are generally considered and are NOT unique to the world of Agile 1. Existing enhance, support & maintain 2. New revenue generating products and services, gain market share in the near term, invest today, realize today 3. Future invest today realize tomorrow, products and services that will grow revenue in outlying years 4. Sunset put the horse out to pasture

12 Epics Portfolio Level Are large scale in nature and are used to realize investment themes Are the highest level of requirement Demonstrate VISION NOT specificity They must be categorized, prioritize and estimated They represent the 2 nd layer of abstraction Agile Requirements

13 Epics Portfolio Level Epics are managed and maintained by the Portfolio management group, governance team or business unit owners Epics are managed and maintained in the Portfolio backlog Investment Themes Epic1 Epic2 Epic3 Portfolio Backlog

14 A note about architectural epics Represent the technological/infrastructure initiatives required to support features Ultimately architectural epics represent large scale implementations that could potentially affect millions of lines of code and how that code will be housed, supported etc.

15 Features Program Level What new things will a system do for its users Describes the benefits the users will get out of features They bridge the gap between needs and Software requirements Problem or Opportunity Solution

16 Features Program Level Simple rule of thumb for features; features ensures that this layer of abstraction is kept at a high level. In essence features are a high level user story and can be written as such As a sales person I want my expenses to be automatically categorized so that I can create my expense reports quickly This layer of abstraction is important for Agile teams to organize teams for development efforts Agile Requirements

17 Features Program Level Challenges in Prioritizing Features for the Program Backlog Customers want them all Product managers want to avoid prioritizing features for sake of having them all Quantification of value for simple must haves is difficult to do for sake of remaining competitive this is often to abstract in nature to prioritize Comparing apple features to oranges features can be very challenging Large features that take months to develop versus must have features that take weeks to develop

18 User Stories Team Level User Stories are NOT Requirements They are a placeholder for requirements to be realized/discussed They are the Value Stream for Users and a direct line to developers for coding The user story is the most critical level of abstraction for Agile environments to succeed Help to bridge developers with customers Agile Requirements

19 User Stories Team Level A user story is a brief statement of intent that describes something the system needs to do for the user Leffingwell Detailed system behavior is NOT captured in a user story Agile Requirements

20 User Stories Team Level Characteristics of a great user story: They are short and easy to read They are captured in a list format large BRD s not welcome here! They can be discarded after implementation They represent small increments of functionality They should be relatively easy to estimate Agile Requirements

21 User Stories Team Level Characteristics of a great user story; Card 2 or 3 sentences to describe intent of story Format: As a <role> I can <activity> so that <business value> Conversation The card in essence is the introduction to a conversation between, product owner, developers, users, team, customer etc, in short all stakeholders involved. The conversation is intended to seek clarity and drive out details Confirmation = Acceptance test, has the story been implemented according to conditions of satisfaction? Agile Requirements

22 User Stories Team Level Characteristics of a great user story; Details of conversation are most often captured as assumptions acceptance criteria, and alternate flows, and are kept as separate notes with the user stories Critical to the success of the user story is acceptance criteria; Acceptance criteria are conditions of satisfaction The best litmus test of user stories is the use of the mnemonic INVEST Independent Negotiable Valuable Estimable Small Testable

23 Pulling it all together

24 Questions? Nancy Y. Nee, PMP, PMI-ACP, CSM, CBAP VP, Global Product Strategy, ESI International