IBM Innovate 2010 Managing Requirements for Your Agile Team

Transcription

1 IBM Innovate 2010 Managing Requirements for Your Agile Team Mia McCroskey Manager, Requirements Management Emerging Health Information Technology RDM-1206A The premiere software and product delivery event. June 6 10 Orlando, Florida

2 Presenter and Organization Mia McCroskey Requirements manager, quality assurance manager, and project manager at Emerging Health Information Technology Certified Project Management Professional Certified SCRUM Master Eleven years in requirements engineering and project management Emerging Health Information Technology Healthcare professional services and consulting firm Subsidiary of Montefiore Medical Center, Bronx, New York

3 Product and Industry Clinical Looking Glass Product Web-based clinical informatics application Accesses the electronic medical record Places patient data analytics in the hands of clinicians Developed by medical informaticists over ten years Health Care Information Technology Increased focus on the electronic medical record puts spotlight on products like CLG Health Information Portability and Accountability Act (HIPAA) requirements must be articulated at data and application levels National mandate to automate and prove meaningful use of patient data Support of quality improvement initiatives

4 Clinical Looking Glass Team Seventeen engineers, testers, analysts, and managers Each wears several hats Strong ALM processes and best practices Strong support for cutting edge and industry standard technologies, tools, and processes Internal shop do not need detailed specifications approved by an external client Implemented Scrum after several years using Rational Unified Process Two Scrum teams of six and seven members, engineers, testers, architect, and business analyst Business analyst and architect on both teams -- they are the Scrum masters External coach through sprints 0 and 1

5 This Iteration Background The Group Mind Requirements in Sheep s Clothing Requirements in Our Bones YAGNI You Ain t Gonna Need It Agile Requirements Lifecycle Practical Examples Conclusions

6 The Group Mind NUM83RS 11 Sprints 81 User Stories 635 Sprint Tasks 520 Requirements 21 Standards and Guidance Documents

7 The Group Mind Spring 2009: CLG Goes Agile! Fall 2009: What did we decide to do about allowing a WITHIN condition to be used as a user-defined duration when browsing results data? By sprint three team members could not recall specific rules and requirements implemented as recently as sprint one.

8 The Group Mind SCRUM Coach: Review the conditions of acceptance in the completed Product Backlog Items TEAM: There are so many! TEAM: I m not sure which sprint it was TEAM: This level of detail wasn t specified in the conditions of acceptance! SCRUM Coach: Review the test cases. TEAM: Which test cases? There are dozens. TEAM: And why do I have to derive the requirement from the expected results? TEAM: What if I misunderstand the intent?

9 The Group Mind During the fifth sprint, a user story introduces functionality that includes display of patient data HIPAA rules apply, which are covered by the Security Audit Inventory, a standards document Product owner does not include the existing security function in the conditions of acceptance Why should he? It s a standard. Mid-sprint the team realizes they didn t include it in estimation or planning Renegotiate with product owner

10 The Group Mind Why was it omitted? The HIPAA function already exists so it s off the radar Business analyst failed to think big picture Team members did not review the standards Team members did not review the requirements model Pressure to keep PBIs small can result in conscious and unconscious deferral of critical requirements User stories are supposed to be independent discourages integrated analysis

11 This Iteration Background The Group Mind Requirements in Sheep s Clothing YAGNI You Ain t Gonna Need It Agile Requirements Lifecycle Practical Examples Conclusions

12 Requirements in Sheep s Clothing Agile model relies on the teams adherence to pre-defined standards. User story need not state anything covered in the standards: User Interface Quality of Service Security Technology The definition of done Is a form of requirement spec Refers to many additional standards documents

13 Requirements in Sheep s Clothing Every Sprint Backlog Item is (supposed to be) reviewed by the team for compliance with appropriate standards before it s considered done. CLG standards and guidance artifacts created or expanded during sprint 0 Global Quality of Service Requirements Scrum Test Practices CLG Personas SQL Server Coding Standards Definition of Done Unit Test Targets Code documentation standards DB Pro Implementation Guidelines Code analysis rules User Interface Standards Client Technology Stack Development Technology Stack Server Environments Security Development Lifecycle process Security Audit Inventory Product Vision Smoke Tests Standards and Guidelines Architecture Guidelines Release Management Process Required UML Management Metrics

14 Requirements in Our Bones Solution strategies for standards ignorance Each team member tends to know some of the standards Develop practice of having standards experts review work before calling it done (Agile? Not so much ) Scrum masters continually remind the teams to double check the standards Eventually standards are absorbed into the bones of the team And then Manage evolution of standards (and they will evolve) Team members will remember they exist if they have to modify them Recognize that nothing is inflexible

15 This Iteration Background The Group Mind Requirements in Sheep s Clothing YAGNI You Ain t Gonna Need It Agile Requirements Lifecycle Practical Examples Conclusions

16 YAGNI You Ain t Gonna Need It Only document what you need when you need it No more specifications! No more sequence diagrams! No more prototypes! Just code it and demonstrate it! Woohoo! It s 1983 all over again!

17 YAGNI You Ain t Gonna Need It What YAGNI really means to the requirements Embrace Just in Time Admit that those thick requirements specs were never complete or correct Be as loyal to your requirements standards as you are to your other definition of done standards But first, modify your requirements standards for agile Capture decisions as they are made If you are fundamentally opposed to calling such decisions requirements then don t. But still capture them.

18 YAGNI You Ain t Gonna Need It Agile Requirements Standards -- Use Case vs User Story Do you still need use cases? Probably not Have the business analyst draft test cases instead same logical exercise results in a usable artifact Take use cases out of your trace matrix, but put in user stories at the top level

19 YAGNI You Ain t Gonna Need It Functional requirements lite Do you really need to specify for each new screen that The system shall provide a means for the user to reset all data fields, and The system shall provide a means for the user to save entered data, and The system shall validate all user entries upon save? No. Your standards should cover these kinds of requirements. They should be ingrained in the bones of your team members.

20 YAGNI You Ain t Gonna Need It Do update your standards as new global requirements emerge Do capture functionality exceptions as requirements But ask, repeatedly, why they exist Do keep functional requirements and test cases in your trace matrix Knowing what you ve tested is still critical Knowing what functionality your automated tests cover is also critical

21 YAGNI You Ain t Gonna Need It Rules Rule The majority of requirements captured during sprints are business rules (facts such as field size limits, algorithms used, not application functionality) You are more likely to need to inform the end user of business rules (e.g., how to specify a wildcard search of a text field) than of functional requirements. Throughout the sprint, business analyst team members update the requirements model as needed to support newly caught business rules and flesh out the trace matrix

22 This Iteration Background The Group Mind Requirements in Sheep s Clothing YAGNI You Ain t Gonna Need It Agile Requirements Lifecycle Practical Examples Conclusions

23 Agile Requirements Lifecycle Vision Phase Iterative cycles of gathering and analysis Six to twelve months ahead of the sprint Stakeholder and marketing participation Decompose epics into user stories Validate with users Validate decomposition with scrum team Prioritize

24 Agile Requirements Lifecycle Conditions of Acceptance Product owner drafts Team members review and propose revisions Only the product owner actually revises them If a user story has more than a dozen (and that s a lot), then They re too granular The user story is too big Conditions of acceptance must all be demonstrated during the sprint review

25 Agile Requirements Lifecycle Analysis During and after sprint kickoff the team analyzes each product backlog item Develop mock-ups, prototypes, and design Surface questions Product owner resolves any business-level issues

26 Agile Requirements Lifecycle Specification Throughout the sprint team members update the requirements model with the COAs and emergent requirements Business analyist informally verifies that the requirement he wrote is what everyone understood No inspections or baselining Determine whether a decision requires a change to a standard

27 This Iteration Background The Group Mind Requirements in Sheep s Clothing YAGNI You Ain t Gonna Need It Agile Requirements Lifecycle Practical Examples Conclusions

28 Practical Examples Agile Requirements Model High level business requirements module contains the user stories, most rewritten as requirements User Story: As a medical researcher I need to define a group of patients from 2009 based on demographics, hospital admission, diagnosis, the outcome of a specific lab test, and the existence of a specific medication order in order to study the effect of the medication on their condition. Requirement: The system shall allow the user to define a patient cohort using calendar time period, demographics, and multiple medical care events. Functional requirements module contains conditions of acceptance plus emergent requirements Business rules module contains static rules (e.g., minimum and maximum length of userentered object names, formula used to calculate binomial confidence interval, etc.)

29 Practical Examples Agile Trace Matrix Omit use cases from the trace matrix Trace from test case to functional requirements and rules, then to global business requirements Associate global business requirements with user stories Non-functional requirements are covered in standards, not duplicated in requirements Performance UI standards compliance Technology constraints Other -ilities

30 Practical Examples Concerns and Practices Can t trace tests to standards at the same level of granularity Can reference a standard in a test case document, but can t link to a specific detail Can t automate a metric for test coverage of standards User stories live in MS Team Foundation Server Manually enter work item numbers (user story numbers) into appropriate attribute in DOORS Add DOORS links to user story work items

31 Practical Examples In DOORS, custom views support granularity Reduce noise for team members working on user stories in specific areas Release-based views inform quality assurance efforts Testing strategy and focus leading up to planned release Not included: Sprint or Team attributes Sprint or Team views You do need to know what requirements were implemented for each release to the public. You do not need to know which sprint they were done in. User stories are volatile enough that managing these attributes would take more time than it s worth. YAGNI!

32 DOORS Examples Engineers use DOORS Web Access and appropriate view

33 DOORS Examples Testing managed in MS Team Foundation Server Test case names entered in a DOORS Test Case module as objects These are linked to all appropriate requirements Area views include test case trace column created with the Analysis Wizard

34 DOORS and TFS Examples Requirements links added to user story work items User story numbers associated with high-level business requirements Relationship is many-to-many Functional requirements and rules are linked to high level requirements

35 TFS Examples Source control change sets linked to product backlog items in MS Team Foundation Server Allows trace from requirement all the way to checked in code

36 Other Artifacts Storyboard Epic user stories Use as paper prototype in user sessions Decompose large decks into user story sized chunks for teams Business analyst captures written requirements only after team analysis and revision during the sprint

37 Other Artifacts Intra-sprint defect log Yes, it s a spreadsheet. Remember what I said about 1983? Lasts only for the duration of the sprint Created by the teams, not imposed by management or process

38 Conclusions Background Agile overview The Group Mind Requirements in Sheep s Clothing Requirements in Our Bones YAGNI You Ain t Gonna Need It Agile Requirements Lifecycle Practical Examples Conclusions

39 Conclusions With agile you sweat the requirements details when they arise, in context, and with a well-informed team and product owner No more re-baselining requirements Engineers identifying requirements during design and coding Working with business analyst to document in requirements model (DOORS) In the past, if they found a hole they might just do what they thought best

40 Conclusions Shift away from functional requirements to business priorities Teams understand business drivers Pre-agile requirements were 21% of total effort SCRUM requirements are 9% of total effort Sizing user stories is much, much harder than anyone admits Crafting conditions of acceptance is harder than writing requirements Reorganizing or scaling a less agile requirements model requires analysis and discipline Let go of some detail Turn your process on its head Define new standards and enforce them!

41

42 Copyright IBM Corporation All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.