A Lean and Scalable Requirements Information Model for the Agile Enterprise. About Dean Leffingwell

Transcription

1 12/9/09 A Lean and Scalable Requirements Information Model for the Agile Enterprise By Dean Leffingwell OO Days at TUT Dec 9, 2009 Special thanks to the model s co-author, Juha-Markus Aalto of Nokia About Dean Leffingwell 2 1

2 IT STARTS WITH THE TEAMS The Agile Team in The Enterprise There can be a large number of teams in the enterprise pods of 5-10 teams building a feature, component, or subsystem is not unusual Some product lines require teams to build However, the structure of each team is largely the same H H H H 2

3 The structure of each team is largely the same Their work is based on the user story User As a <role> I can <activity> So that <business value> As a Gmail user, I can select and highlight a conversation for further action 3

4 Stories drive iterations A B C D E F Plan Fixed Resources Fixed Time (Iteration) 7 Stories are implemented by tasks 51 As a user, I can highlight a conversation for further action Task 51.1 Review acceptance test Task 51.2 Code story Task 51.3 Code acceptance test Task 51.4 Get it to pass Task 51.5 Document in user help Juha, Dean, Bill Juha Bill Juha and Bill Cindy Implemented by 1 Task Tasks are used by the team to estimate and coordinate the effort required to deliver a story into the baseline 4

5 Tasks are either The only reasonable way to: Coordinate interdependencies Take individual responsibility for work Break a story down into small enough chunks (hours) to be truly estimable Track story completion, task by task Or Needless, non-lean administrative overhead 9 Stories are maintained in the teams backlog There is only one backlog for the team Backlog Item All work comes from the backlog Is one of If isn't a user story (defect, etc) it still goes in the backlog Implemented by 1 Task 5

6 User : The 3 C s Card Written on card or in tool and may annotate with notes Conversation Details in conversation with product owner Confirmation Acceptance tests confirm the story correctness As a user, I can log in to gain access to the internet What about expired accounts? Expired accounts fail Returning power users automatically log in Remember login name 11 A Pidgin Language? A pidgin language is a simplified language, usually used for trade, that allows people who can't communicate in their native language to nonetheless work together. User stories act like this. We don't expect customers or users to view the system the same way that programmers do; stories act as a pidgin language where both sides can agree enough to work together effectively. -- Bill Wake xp123.com/xplor/xp0308/index.shtml 12 6

7 Details as Acceptance Tests Support Master Card & Visa Don t support American Express Send confirmation of selected service Can choose 1 hour or 1 day of access Verify that an expired card fails Verify that discount is applied with customer coupon 13 Confirmation - all code is tested code Backlog Item Stories can t be considered done until they pass an acceptance test Is one of Stories must be integrated into the baseline to be accepted Done when passes 1 Implemented by 1 Task The Product owner is usually responsible for accepting the story Acceptance Test 7

8 A test and quality-centric approach Teams perform unit testing and functional testing for every story Backlog Item Is one of The details of the story go into the functional test, where they are the persistent representation of system behavior Done when passes 1 Implemented by 1 Task Stories are temporal (not maintained after implementation) Acceptance Test 1 Consists of Unit Test Functional Test The model for agile teams is lean and scalable 16 8

9 BUT WE HAVE TO SCALE THE MODEL FOR AGILE PROGRAMS Which requires rethinking Assume a program requires 200 practitioners, (25 agile teams) to deliver a product The enterprise delivers software every 90 days in five, two week iterations. Each team averages 15 stories per iteration. Number of stories that must be elaborated and delivered to achieve the release objective = 25*5*15= 1,875! How is an enterprise supposed to reason about things? What is this new product going to actually do for our users? If we have 900 stories complete, 50% done, what do we actually have working? How would we describe 900 things? How will we plan a release than contains 1,875 things? And, what if it took 500 people? 18 9

10 And further And, even if I know 100 things that as a <role> I can <activity> so that <business value>, can do what Features does the system offer to its user and what benefits does it provide? Feature Stars for conversations Benefit Highlight conversations of special interests Colored label categorization Easy eye discrimination of different types of stories (folder like metaphor) Smart phone client application Faster and more facile use for phone users ease adoption 19 So we need two levels of planning Features Product & Release Cycle Release Planning Release Vision Release Scope and Boundaries Drives Stories Iteration Cycle Iteration Planning Feedback - Adjust Review & Adapt Develop & Test 20 10

11 Which creates an iteration and release pattern Stories Release timebox 21 So we need to extend the information model Features are another kind of Backlog Item Backlog Item Is one of Feature Realized by 0,1 Implemented by 1 Task Introduce Gmail Labels as a folder-like conversationorganizing metaphor. Or: As a modestly skilled user, I can assign more than one colored label to a conversation so that I can see a conversation from multiple perspectives 11

12 12/9/09 Which creates a bigger Big Picture Teams of teams may be organized by technology domain, product, or product line, system or subsystem 2009 Leffingwell, LLC. Inspired by collabora;on Leffingwell, LLC. & Symbian SoFware Ltd. H H H H Features also require testing Backlog Item Is one of Feature Realized by 0,1 1 Implemented by 1 Task 1 Done when passes And maybe a new team.. Features typically span many teams Acceptance Test Sometimes, a special team is dedicated for the purpose of testing system level features 12

13 What about non-functional requirements? Features and user stories express functional requirements But other requirements (NFRs) determine system quality as well: Performance, reliability and security requirements Industry and Regulatory Standards Design constraints, such as those that provide common behavior across like components Typically, these system level qualities Span multiple components/products/applications/ services/subsystems Can often only be tested at the system level 25 NFRs can be considered as constraints on new development When we add labels to conversations, we still have to meet the accessibility standards. Backlog Item Is one of Constrained by 0..* 0..* Non-functional Requirement Feature Realized by 0,1 1 1 Done when passes Implemented by 1 Task Acceptance Test 13

14 Which must also be tested Often requires specialty skills and tools May also be province of system team Backlog Item Is one of Constrained by 0..* 0..* Compliant when passes Non-functional Requirement 0..* System Validation Test 1 Feature Realized by 0,1 1 1 Done when passes Implemented by 1 Task Acceptance Test Summary for Agile Programs: Is the model still lean and scalable? 14

15 12/9/09 SCALING TO THE PORTFOLIO For discussion, see Leffingwell, LLC. Inspired by collabora;on Leffingwell, LLC. & Symbian SoFware Ltd. H H H H 15

16 At the enterprise portfolio level, even system features may be too fine grained There may be dozens of concurrent programs Each delivering dozens of features to market How do portfolio managers communicate the sweeping, larger scale initiatives that drive all those programs? We use the word Epic to describe this content type 31 Epics drive programs with features Epics are key value propositions that create competitive advantage Epic may be implemented over long periods, even years Backlog Item Is one of Constrained by * Non-functional Requirement Compliant when passes 0..* System Validation Test Epic Realized by Feature Realized by 0,1 0,1 1 1 Implemented by 1 Task Abstract, high level, visionary Done when passes Acceptance Test 16

17 Epics, Features and Stories Term Interest Size/Lifespan Testable Epic Business May span several GA releases No Feature User Business, Customer, User Product owner, Team, User Generally fits in one GA release (But may also be versioned across releases) Demonstrable functionality, fits in one team iteration. Otherwise split. Yes Yes 33 Themes represent investment priorities Themes are key product value propositions that provide marketplace differentiation and competitive advantage. Themes are allocated, not prioritized 1H 2009 Investment Priorities Theme 5 27% Theme 1 27% Introduce voice and video chat from within mail Desktop client integrations Mail for Mobile 2.0 Group chat from within mail Theme 4 14% Theme 3 10% Theme 2 22% 34 17

18 Why not forced-rank prioritization? Themes are designed to be addressed on a percentage of time to be allocated basis. Different from user stories and features example: lowest priority story on an iteration backlog may not be addressed at all in an iteration and yet the iteration could be a success (meet its stated objectives). However, if the lowest priority (smallest investment mix) theme is not addressed over time, the enterprise may ultimately fail in its mission by not making its actual investments based on longer term business priorities 35 FINALLY, A FULLY EXPANDED MODEL FOR AGILE PORTFOLIO MANAGEMENT 18

19 A fully elaborated model for the agile enterprise Backlog Item Is one of Constrained by * Non- func;onal Requirement Compliant when passes 0..* System Valida;on Test Investment Realized by Themes 0, 1 Epic Realized by Feature Realized by 0,1 0,1 * Implemented by 1 Task version Is one of User Other Work Item Done when passes Acceptance Test 1 Consists of Unit Test Func;onal Test Summary Is the model still lean and scalable, really? 38 19

20 In conclusion - caveats This is only a model; there is no UML for agile things If you don t need it all, don t use it all In any case, always do the simplest thing that can possibly work 39 END 40 20