Gathering Customer Requirements in an Agile Environment Mariusz Chrapko ReConf 2009, Munich
Mariusz Chrapko Now: Process Consultant/ Agile Coach@Kugler Maag CIE, Stuttgart Supported Areas: - CMMI - SPICE/ ISO 15504 (Provisional SPICE Assessor) - Agile Software Development (Certified SCRUM Master) Before: Software Quality Engineer/ Agile Coach, Motorola, Poland My Public Profile: http://www.linkedin.com/pub/0/966/67a Page 2 11. März 2009
KUGLER MAAG CIE is a service company with acknowledged expertise in process improvement Facts Founded in 2004, today around 70 acknowledged experts Specialized on process improvement Expertise in CMMI, SPICE / ISO 15504, Functional Safety / IEC 61508, Project-, Quality-, Requirements-, Change Management Industries Automotive Industry, Financial Services, ICT, Health, Telco and Railways Customers Global players, culturally diverse, operating in Europe, North America and Asia Partners & Networks MBtech Page 3 11. März 2009
We already work predominantly for international big companies in different industries, including DAIMLER Page 4 11. März 2009
Introduction Software requirements is a communication problem Those who want software must communicate with those who will build it Page 5 11. März 2009
Balance Is Needed If either side dominates, the business loses If the business side dominates functionality and dates are mandated with little regard for reality or whether the developers understand the requirements If the developers dominate technical jargon replaces the language of the business and developers lose the opportunity to learn from listening Page 6 11. März 2009
Our Top Requirements Issues Unable to provide linkage to revenue impact of a feature (it s ROI, cost to develop and potential sales) Unable to link requirements to the market/business needs Missing Requirements Requirements are discovered too late in the product development life cycle Some stakeholders are missed from the requirements development Ambiguous Requirements Project Requirements are not approved by all stakeholders in an appropriate time-frame Page 7 11. März 2009
Context Matters Balance is needed! Agile Page 8 11. März 2009
What Is Agile? Agile describes an approach to a method, not the method itself Under this broad umbrella sits many more specific methods such as Extreme Programming, Scrum, Lean Development, etc. Each community follows the same broad principles (improved communication, working software, customer collaboration, feedback, simplicity, responding to change) Page 9 11. März 2009
Page 10 11. März 2009 Agile Manifesto
Agile vs. Waterfall Requirements Requirements Analysis Design Code Test Deliver Waterfall Project Planning and Tracking Agile R D T R D T R D T R D T R D T R D T R D T R D T R D T R D T R D T R D T R D T Code Code Code Code Code Code Code Code Code Code Code Code Code R D T R D T R D T Code Code Code R D T Code Deliver Page 11 11. März 2009 Coaching and Tracking
SCRUM Lifecycle 24 hours/daily Scrum Sprint Planning Time Boxed Sprint 2-4 weeks Cancel PRODUCT BACKLOG SPRINT BACKLOG PRODUCT INCREMENT Sprint Review Page 12 11. März 2009
SYNERGY Collaborative Design Test Driven Development Automated Regression Frequent Integration Refactoring Pair Development XP@SCRUM Page 13 11. März 2009
SCRUM Roles And Responsibilities Product Owner Defines the features, decides on release date and content Prioritizes the Product Backlog Can change features and priority every sprint Accept or rejects work results Attends Sprint Planning and Review Meetings Scrum Master Team Ensures that the team is fully functional and productive Enables close cooperation across all roles and removes barriers Shields the team from the external interferences Ensures that the process is followed Participates in Daily Scrum, Sprint Planning and Review Meetings Typically 5-9 people Selects the Sprint Backlog Has the right to do everything within the boundaries of the project guidelines to reach the Sprint Goal Organizes itself and its work Demos work results to the Product Owner Page 14 11. März 2009
Requirements Development Process Develop Customer Requirements Develop Product Requirements Analyze and Validate Requirements Page 15 11. März 2009
Product Backlog = Requirements This is the product backlog A list of all desired work on the project Ideally expressed such that each item has value to the users or customers of the product Prioritized by the Product Owner Reprioritized at the start of each sprint Page 16 11. März 2009
The Product Backlog All possible system features are captured in a prioritized list the Product Backlog New features can be added at any time to the Product Backlog by anyone Features have only a gross estimate of effort and value Product Owner prioritizes the Product Backlog Each Sprint implements the highest value features High value Low value Features Each new feature is prioritized and added to the stack Features may be reprioritized at any time Features may be removed at any time 2004, Scott W. Ambler Page 17 11. März 2009
Turning Backlog into Product High value Business Goals Low value Products (months-years) Releases (weeks-months) Sprints (10-30 days) Tasks (1-16 hours) Page 18 11. März 2009
Levels Of Requirements Page 19 11. März 2009
User Story Template Originally extreme Programming described a user story as a small amount of text written on an index card to function as a reminder for a conversation between developer and customer The user story form credited to Rachel Davies in Cohn s User Stories Applied combines user, task, and goal: As a [type of user] I want to [perform some task] so that I can [achieve some goal] Page 20 11. März 2009
User Stories: Sample #1 As a scientist I want to have application that multiply two numbers to perform my work!!! Page 21 11. März 2009
User Stories: Sample #2 Page 22 11. März 2009
User Stories: Sample #2 As a scientist I want to have application that multiply two numbers chosen by me to perform my work!!! Brrr... It s useless. I have to multiply different numbers! Page 23 11. März 2009
User Stories: Sample #2 Page 24 11. März 2009
User Stories: Sample #2 As a scientist I want to have application that multiply two numbers chosen by me from range [-100,100] to perform my work!!! Brrr... It s useless, again. I have to multiply more different numbers! Page 25 11. März 2009
User Stories: Sample #2 Page 26 11. März 2009
User Stories: Sample #2 It meets my requirements! Page 27 11. März 2009
User Stories: Sample #2 As an user I want application to start and run smoothly to perform my work. As an user I want application to start in 5 seconds and has response time not more than 1 second to perform my work. As an user I want application to start in 5 seconds and has response time not more than 1 second on recommended hardware and operating system configuration to perform my work. Page 28 11. März 2009
Flow Of An Iteration Backlog (Stories) The Developers/Testers After Stories iteration development exist test the demo planning, the feature marks has backlog take been the against the customer, and Acceptance frozen, completion the are pulled of testers, Tests Acceptance into the iteration as will and iteration requirements. execute developers Tests in which to (a the be story developed the Acceptance work is developers not together complete during Tests to will and other test scenarios. They will give demo develop until all the the Acceptance iteration planning Tests Tests pass). to (Must the During be development feedback during this customer completed this stabilization time, to testers before prove period give development the which feedback implemented will allow begins) to for the functionality development has to resolve met their any needs. issues. resolution of defects or failing Acceptance Tests. Iteration X: AT s (Story 1) Development Stabilize Story 1 Story 2 Story 3... AT s (Story 2) AT s (Story 3) AT s (...) Test Demo Page 29 11. März 2009
ScrumWorks Tool Page 30 11. März 2009
Burndown Chart In ScrumWorks Tool Page 31 11. März 2009
And Another Tools Page 32 11. März 2009
Why User Stories Stories are comprehensible - Developers and customers understand them - People are better able to remember events if they are organized into stories Support and encourage iterative development Stories are the right size for planning Stories support participatory design Page 33 11. März 2009
Why NOT User Stories On a large project there can be lots of stories Solution is to remember to keep some as epics initially or staple some together into themes Stories on cards don t facilitate traceability But you can do it, or you can use software Stories focus on increasing tacit, not formal, communication May need to supplement with some formal documentation Page 34 11. März 2009
Page 35 11. März 2009 QUESTIONS?
THANK YOU! Mariusz Chrapko mariusz.chrapko@kuglermaag.com KUGLER MAAG CIE GmbH Leibnizstraße 11, D-70806 Kornwestheim/ Stuttgart Phone / Fax +49 (0) 7154 807 210 / 229 Page 36 11. März 2009