Embedded Storycrafting: Key to Controlling Risk and Schedule

Transcription

1 Embedded Storycrafting: Key to Controlling Risk and Schedule Agile 2011, Salt Lake City Nancy Van Schooenderwoert Lean-Agile Partners Inc. All rights reserved. 1

2 Nancy V s Background 15 years safety-critical systems experience 11 years agile team coaching 4 years agile enterprise coaching Industries: Aerospace, Medical Devices, Sonar Weaponry, Scientific Instruments, Financial Services Electrical Engineering and Software Engineering, embedded systems 2

3 Message We re not getting all we can from Agile Story basics let s use them better And we can get lots more by modest extensions: Building Block stories Do-er role Perhaps others 3

4 Why Storycrafting? Because there is a real craft to using Agile Stories well Context matters Stories evolve Embedded storycrafting addresses these for the software + hardware world 4

5 Format of a Story As a <role, beneficiary> I want <capability> so that <benefit> <role> is the customer of the Story <capability> is what <benefit> is why Conditions of Satisfaction <Facts that would demonstrate capability exists> 5

6 Example story HART Bus Can you see customer, what, why in this Story? Story System can read a single HART value at a fixed address Narrative details to be captured in documents Conditions of Satisfaction Get expected response to Cmd #1 with Single master Using present hardware Update < 1 second CoS becomes the root of story acceptance test This team s Story doesn t follow the template fully, but CoS is well stated 6

7 How strict? Do we always have to follow the form exactly? No, but consider trying it What problems happen if it s not used? Without the why info, can miss oppty to invent better solution (no symptom) Harder to spot best way to split Stories When CoS matches Customer, easier to get Story accepted 7

8 Story Context Is using present hardware ok? Conditions of Satisfaction Get expected response to Cmd #1 with Single master Using present hardware Update < 1 second You cannot answer based on what is written here. If the team has already discussed this story and they understand present hardware then it s clear enough prior to estimation work*. If the story was written just now, and Team has not discussed it, the Team may need it clarified. * In a regulated environment the h/w setups will be documented, as actually required. 8

9 Example story Camera Story As a software developer I want a link to camera to send commands, get status Conditions of Satisfaction Command triggers status response in <= 300 ms Do 2 commands/ sec Comms faults not handled Narrative details to be captured in documents CoS becomes the root of story acceptance test 3 rd bullet added by Team during estimation exercise. Stories evolve. 9

10 Story Evolution First version may hold one person s understanding of the need Conversation sharpens up the Story May change wording May change CoS (e.g. to control scope) May split the Story 10

11 Aerospace Story headlines Aero project laundry list Transmit EICAS ARINC label (no data) EICAS WOW Indication EICAS Gear not in demanded pos n ind. EICAS Gear locked down ind. WOW i/p error checks.. Do your Stories look like this? Headline form is a starting point. Let s flesh-out one of these... 11

12 Story: EICAS WOW Indication Aero project laundry list Transmit EICAS ARINC label (no data) EICAS WOW Indication EICAS Gear not in demanded pos n ind. EICAS Gear locked down ind. WOW i/p error checks.. As a software developer I want to see WOW ind. on EICAS ARINC label. Conditions of Satisfaction: One list item cast into Story form MCDC test on 3 gear i/ps Response within 100 ms (no error checking) 12

13 Embedded stories are techy Transmit EICAS ARINC label (no data) EICAS WOW Indication EICAS Gear not in demanded pos n ind. EICAS Gear locked down ind. WOW i/p error checks.. So you need a key! Rule: All terms understandable by Team & Customer Glossary EICAS = Engine Indication Crew Alert System ARINC = Aeronautical Radio Incorporated WOW = Weight on wheels Ind. = indication i/p = input, inputs MCDC = Modified Condition Decision Coverage 13

14 Multiple customers This story benefits different roles, at different times As a customer I want 10GB extra Flash memory for bigger troubleshooting log and 2 more languages Arabic, Urdu Conditions of Satisfaction:. Which role uses the software trouble-shooting log? Which role installs new language support? When are each needed? 14

15 Splitting stories Break story first by time its parts are needed As a customer I want 10GB extra Flash memory for bigger troubleshooting log and 2 more languages Arabic, Urdu Conditions of Satisfaction:. As a developer I want 10GB extra Flash memory for bigger troubleshooting log. CoS:. As customer internal support tech I want 10GB extra Flash memory to load 2 more languages Arabic, Urdu. CoS:. 15

16 Splitting stories (continued) Always split Story initially by time if applicable EARLY LATER As a developer I want 10GB extra Flash memory for bigger troubleshooting log. CoS: All bits pass R-W test No cut traces on board As customer internal support tech I want 10GB extra Flash memory to load 2 more languages Arabic, Urdu. CoS: All screens use Arabic, Urdu Keypad allows lang. symbols Can select Arabic, Urdu Splitting the Story simplifies CoS for both new Stories. Allows 2 smaller Stories to sit cleanly on the timeline. 16

17 Splitting stories (continued) Development Field trials Cust. delivery Time Now you can position supporting Stories Extra Flash for developer Extra languages for support tech Upgrade board Prep translations Language uploader 17

18 Mini Review Getting more from Story basics: Canonical form Context Evolution Language Splitting 18

19 5 Levels of Story Evolution 1. A laundry list item 2. Story with CoS (Conditions of Satisfaction) As a <role> I want <capability> so that <benefit> 3. Story estimated by Team in story points 4. Story broken into tasks estimated in hours by Team Happens at Iteration Planning meeting 5. Additional Story detail pulled during iteration 19

20 5 Story levels example Time Fluid level measurement mode As a developer I want to get a Level value over debug communication so I can troubleshoot problems. Story Accuracy > 2mm No fast movement No error check or broken wire check 1 2 Identified in early product feature conversations by anyone Elaborated into form of Story plus Conditions of Satisfaction which define what DONE means. Conditions of Satisfaction 20

21 5 Levels example Time 3 pts As a developer I want to get a Level value over debug communication so I can troubleshoot problems. Story Accuracy > 2mm No fast movement No error check or broken wire check Only motion < 2mm/sec 3 Story points estimate made by team, after discussion. Story and CoS wording may be revised during discussion. Conditions of Satisfaction (CoS) Wording added by Team 4 Story work broken into tasks, each estimated in hours by team. Done at start of iteration. 5 Just-in-time details may be received during iteration; info that was not needed for the estimating. 21

22 Extending the Story Form Some modest extensions help when building embedded applications They are not exclusive to embedded First, a look at the problem we re addressing 22

23 The Problem????? Time PROJECT START First Release Early work no perceived customer value Later stories that have customer value Early stories are building-block stories But: All work should have customer value, right? 23

24 Deliver in Working Increments One iteration Many Iterations GUI APP LIB OS FIRMWARE BOARD A given story might not slice through all architectural layers Often necessary to keep stories small enough. Use spike stories when possible. 24

25 Layers of Customers First iterations serve near customers s/w troubleshooters Prototype assembly people Mechanical engineers S/W Team Building a blood analyzer Self Algorithm designers Electrical engineers Sensor designers Electrical engineers Electrical engineers Regulators, Partners, Suppliers, Hospital adm, Physicians, Patients 25

26 Format of a Story As a <role, beneficiary > I want <capability> so that <benefit> <role> is the customer of the Story <capability> is what <benefit> is why Missing is the Do-er; the performer of the Story s work (Team is the implied Do-er, but we have closely cooperating teams: Software, EEs, MEs, etc. ) 26

27 An Embedded Story As a Software Developer I want an extra I/O pin brought out so that I can monitor task entry/ exit on the oscilloscope What Why Customer Do-er? The Do-er is implied by which Backlog the Story is in. 27

28 An Embedded Story (again) Customer Do-er As a Software Developer I want EEs to bring out an extra I/O pin so that I can monitor task entry/ exit on the oscilloscope This way all stories could go into one Backlog. Why What 28

29 S/W is Customer of H/W Volt Mon Story As a Software Developer I want an extra I/O pin brought out so that Customer I can monitor voltage level A/D counts on test point 3A Conditions of satisfaction: I can easily get a probe onto the pin Do-er H/W Pin is accessible with cover on 29

30 H/W is Customer of S/W Volt Disp Story Customer As an Electrical Tech, I want to see test point 3A voltage on the display so that I don t have to open the unit in the field to check it. Do-er Conditions of satisfaction: Value is displayed when * key pressed, in test mode S/W Value is in volts Displayed value updates within 0.1 sec of change to actual 30

31 Customer layers & story paths Volt Mon S/W Team Self EEs MEs Algorithm designers Scientist Volt Disp S/W is customer for Volt Mon, EEs are customer for Volt Disp. Other layers will also use Stories as flexible micro contracts. Note: EEs is Electrical Engineers. MEs is Mechanical Engineers. 31

32 Building Block Stories Both the previous stories are building blocks They carry no customer value (to the paying customer) Iterations with internal customers control risk during early work project period No Building Block Stories unless they support an End-customer Story! 32

33 What About Phase Gates?????? Time PROJECT START EARLY WORK First Release LATER STORIES Traditional Team: In this period they build docs taking all features thru phase 2 or 3, based on early knowledge. Agile Team: In this period modeling, investigating, some features started, some infrastructure work completed. Traditional Team: They are just starting to build real features. They find that much of their plan is wrong and must be reworked. Agile Team: Most risks already driven down, some infrastructure ready, and team is completing the rest of the features. 33

34 Other Questions What about the ilities? As before must test for them iteratively What about modeling and UML charts? They re good use them; Stories are for communicating between Do-er, Customer Don t stay with models too long Where s the rest of the documentation? Stories are the first kernel of it keep going! 34

35 Questions (continued) Can customer be a thing? I like to use Stories between people There are many types of models to explore interactions between components What about spike stories? Still a great idea use whenever you can What about specifying by Example? Very powerful use it! 35

36 Product Evolution via Stories All these evolve as a side-effect when the voices of Customer and Engineering bring a Story to maturity. Agile Story What to build Estimate Architecture Risk Plans Test Approach QA Approach 36

37 Controlling Risk & Schedule Well crafted Stories: Have clear CoS, based on the customer identified Clarify scope with CoS Avoid rework through clear done-ness criteria Let Team access deeper knowledge they have by knowing why the capability is needed Use Building Block Stories and Do-er role to let internal customers guide early infrastructure development 37

38 Sources, Further Reading Sources User Stories Applied by Mike Cohn Story examples are from many teams coached, and attendees of my course Advanced Agile Embedded Workshop Books for further reading Agile Estimating & Planning by Mike Cohn Lean Software Development series by Mary and Tom Poppendieck (basics of how lean for manufacturing differs from lean development) Public Appearances Course: Software Quality and FDA, Boston MA, Oct 4, 2011 Keynote: Software Quality Day, Nuremberg, Germany: Nov 2-3, 2011 Contact: More info at: 38