1. Customer Collaboration

2. Central Principles The customer is part of the team The customer plays key role in directing the team 1

3. XP Collaboration with Customers 1.Customers & Engineers- Collect user stories 2.Engineers- Identify tasks 3.Engineers- Estimate effort 4.Customers- Prioritize stories 5.Engineers- Plan work 6.Engineers- Communicate progress 7.Customers & Engineers- evaluate results 2

4. User Story Fits easily on 3x5 note card Can also be typed into spreadsheet… But harder to review with customers Name + short description 3

5. User Story: Example Title: View eco-friendliness Description: The e-commerce website users can click on a product and view its eco-friendliness ratings. 4

6. User Story: Example Title: Upload eco-friendliness data Description: Trusted 3 rd parties can upload an XML document specifying eco-friendliness ratings for products. 5

7. User Story: Principles Not written in stone Revision is acceptable and expected Fuzzy Further communication is usually needed Minimalist If you add stuff that the customer doesn’t want, then the system will surely cost too much Backed up by acceptance tests To be discussed in a later lecture.. 6

8. User Story: How to Collect Gathering user stories Have a starting point in mind Let the customer walk through the vision “Chunk” the vision into user stories Ask questions to clarify Don’t invent stories; let customer “drive” Remind customer that they can add stories later 7

9. Identify Tasks Systematically break down each user story into pieces of work Can often be decomposed similar to architecture E.g., object, process, feature, process etc. E.g., “first we’ll implement this change to the system, … then this change, … then this change, etc. 8

10. Identify Tasks: Example Helpful to sketch an architecture 9 PHP/Apache Mysql E-commerce interface Databas e Linux UI to upload watchdog data Shopping users Watchdog XML docs

11. Identify Tasks User story: View eco-friendliness Set up a database to store product data / ratings Create web page to show a product’s data Create web page listing products, so user can click 10

12. Identify Tasks User story: Upload eco-friendliness data Set up a database to store product data / ratings Create a web page for uploading XML document Write code to read data into database 11

13. Effort Estimates Figure out effort of each task Estimates done in nebulous “unit” of your own calibration Typically based on experiences with similar work If needed, do a spike (an experimental implementation) to estimate difficulty Take “bids” from team members for the lowest effort on each task Sum up task efforts to compute story effort Tweak the estimate as appropriate 12

14. Effort Estimates: “Unit” A unit - how much work you can finish in a week’s iteration To start with, a unit could be defined as how much an average pair of programmers could accomplish in an “ideal“ day E.g., 8-person team has 4 pairs. Each pair can complete 5 “units” per week Team can do 20 “units” per week 13

15. Effort Estimates: Example User story: View eco-friendliness 1u: Set up a database to store product data / ratings 1u: Create web page to show a product’s data 1u: Create web page listing products, so user can click 3 units of effort 14

16. Identify Tasks User story: Upload eco-friendliness data 1u- Set up a database to store product data / ratings 0.5u?- Create a web page for uploading XML document** 1u- Write code to read data into database 2.5 units of effort 15 ** Not sure? May call for a spike!!

17. Be Empirical When in doubt, do a spike What it is: a small program that explores / tests possibilities How to do it: Identify one key to discover Write a little code to test an idea Tweak code until you get info you need Throw code away, keep the knowledge 16

18. Effort Estimates: Be Conservative Conservative estimates based on each user story Don’t assume a certain ordering of user stories You will over-estimate effort Accurate effort estimates takes experience 17

19. Effort Estimates: Be Realistic Expected to work at a sustainable pace No heroes, no all-nighters, no super-human feats Either you’ll get the code done like a human being, or you don’t 18

20. Effort Estimates: Be Honest Engineers should give honest estimates customers can trust Engineers make estimates Customers make priorities XP Saying: “He who does the work sets the estimate.” 19

21. Effort Estimates: Customers Prioritize Stories Customers makes business decisions Engineers make technical decisions Don’t “steer” the customer Do help customer understand consequences of choices Do NOT try to persuade customer of priority ordering 20

22. Planning Work Once customer has chosen stories, teammates get organized Decide who will perform each story’s task Figure out how to work in pairs Plan how to avoid stepping on each other’s toes Finalize your development environment 21

23. Planning Work: Examples Monday: Jim & Peg Set up a database to store product data / ratings (1u) Load with two sets of test data Tuesday / Wednesday: Jim & Joe Create web page to show product’s data (1u) Create web page listing products, so user can click (1u) Use one set of test data for unit tests Tuesday / Wednesday: Peg and Phil Create a web page for uploading XML document (0.5u) Write code to read data into database (1u) Use the other set of test data for unit tests 22

24. Communicating Progress Track effort using PSP or similar technique PSP- personal software progress Track velocity- how many units per week? Constantly refine understanding of your capabilities All news (good or bad) should be communicated early Keep the customer informed of good & bad news Keep your team informed, too Release dates don’t slip; functionality slips May be necessary to delay user stories Customer prefers 3 fully-working user stories over 6 half-working 23

25. Communicating Progress: Examples Monday: Jim & Peg Set up a database to store product data / ratings (1u) Monday at noon: “DONE! Everybody should log in and try the DB” Tuesday / Wednesday: Jim & Joe Create web page to show product’s data (1u) Create web page listing products, so user can click (1u) Wednesday: “Finished story and completed integration test” Tuesday / Wednesday: Peg and Phil Create a web page for uploading XML document (0.5u) Write code to read data into database (1u) Wednesday: “Not done yet… probably tomorrow @ noon” 24

26. Evaluating Results: Continual Testing Unit tests Each pair responsible for writing tests, then writing code to satisfy tests Integration tests Several times during the week, check if pieces work together properly Acceptance tests Customer tests the system upon receiving it 25

27. Evaluating Results: After the Iteration Debrief (without customer present) Discuss what went well, what didn’t Assess your productivity Refine estimates of remaining tasks / user stories Evaluate release Customer runs acceptances tests Discuss what works, what to do next 26

28. Evaluating Results: Example Debrief Setting up database was faster than expected Jim was good at setting up database Have Jim teach this during future pairings Peg & Phil struggled with XML file upload Maybe pair them differently? Need a different file upload component? What files will be delivered during release? Configuration instructions? 27

29. Evaluating Results: Release Customer tries out acceptance tests User interface isn’t what customer expected Sketch some changes on paper Staple to the user story Customer shares five other ideas for extending vision Engineers write them as new user stories Launch into next iteration (estimating effort) 28

30. Next Steps… HW #4 (Design) due Friday!! Vision statement peer review next Tuesday!! Bring hard copy of rough draft Don’t forget your midterm!! Due 11/25 29