Embedded storycrafting
- 1. 9/10/11 Embedded Storycrafting Key to controlling risk and schedule Nancy Van Schooenderwoert http://www.leanagilepartners.com/ [email protected] © 2008-11 Lean-Agile Partners Inc. All rights reserved. 1 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 1
- 2. 9/10/11 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 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 2
- 3. 9/10/11 What’s the Point? Idea to Action 5 Ideas to Action Can we get to MMF? Minimum Marketable Feature-set M1 M2 M3 “Now” £ Need early feasibility estimate Need detailed design (of each feature) ready ‘just in time’ 6 3
- 4. 9/10/11 Each feature goes thru… Features travel from ‘Idea’ to ‘Done’ Agile Story format is one way to make that happen Idea Coarse Ready to Done Estimate build Communications about WHAT to build Communications about HOW to build 7 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> 8 4
- 5. 9/10/11 Example story – Pedometer Can you see customer, what, why in this Story? Story Conditions of Satisfaction As a runner I want to • See accurate step count upload my paces with one on my Facebook page button press so I can • Record up to 6 hrs steps compare with my work • Car ride does not mates increment # of steps 9 Example story – HART Bus Can you see customer, what, why in this Story? Story Conditions of Satisfaction Get expected response to System can read a single Cmd #1 with HART value at a fixed • Single master address • Using present hardware • Update < 1 second Narrative details to be CoS becomes the root of captured in documents story acceptance test This team’s Story doesn’t follow the template fully, but CoS is well stated 10 5
- 6. 9/10/11 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 11 Story Context Is “using present hardware” ok? You cannot answer based on what is written here. Conditions of Satisfaction If the team has already discussed Get expected response to this story and they understand Cmd #1 with • Single master “present hardware” then it’s clear • Using present hardware enough prior to estimation work*. • Update < 1 second 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. 12 6
- 7. 9/10/11 How much context? Only what is needed to go from “Idea” to “Coarse Estimate” Don’t say all that can be said about a feature; Just cover what has a bearing on size of the job Idea Coarse Estimate Requires mainly discussion of WHAT to build, and some discussion of HOW to build it 13 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 14 7
- 8. 9/10/11 Example story – ‘Camera’ Story Conditions of Satisfaction As a software developer I • Command triggers status want a link to the camera response in <= 300 ms to send commands, get • Do 2 commands/ sec status • Comms faults not handled Narrative details to be CoS becomes the root of captured in documents story acceptance test 3rd bullet added by Team during estimation exercise. (Handling comms faults makes the job much bigger.) Stories evolve. 15 8 Storycrafting Techniques Context matters Stories evolve Use language of project community Find the first customer Find the Conditions of Satisfaction Customer shadows Building-block stories for customer layers Do-er role 16 8
- 9. 9/10/11 Aerospace Story headlines Aero project “laundry list” Transmit EICAS ARINC label (no data) Do your Stories EICAS WOW Indication look like this? EICAS “Gear not in demanded pos’n” ind. EICAS “Gear locked down” ind. WOW i/p error checks ‘Headline form’ is a starting point. ….. Let’s flesh-out one of these... 17 Story: EICAS WOW Indication One list item cast into Aero project “laundry list” Story form Transmit EICAS ARINC label (no “As a software developer I data) want to see WOW ind. on EICAS WOW Indication EICAS ARINC label.” EICAS “Gear not in demanded pos’n” ind. Conditions of Satisfaction: EICAS “Gear locked down” ind. MCDC test on 3 gear i/ps WOW i/p error checks Response within 100 ms ….. (no error checking) 18 9
- 10. 9/10/11 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. Glossary WOW i/p error checks EICAS = Engine Indication Crew Alert System ….. ARINC = Aeronautical Radio Incorporated WOW = Weight on wheels So you need a key! Ind. = indication i/p = input, inputs Rule: All terms understandable by Team MCDC = Modified Condition & Customer Decision Coverage 19 8 Storycrafting Techniques Context matters Stories evolve Use language of project community Find the first customer Find the Conditions of Satisfaction Customer shadows Building-block stories for customer layers Do-er role 20 10
- 11. 9/10/11 Multiple customers… This story benefits different roles, at different times… Which role uses the “As a customer I want 10GB software trouble-shooting extra Flash memory for bigger troubleshooting log log? and 2 more languages – Arabic, Urdu” Which role installs new language support? Conditions of Satisfaction: When are each needed? …. 21 Splitting stories Break story first by time its parts are needed “As a developer I want 10GB extra Flash memory for bigger troubleshooting log.” “As a customer I want 10GB extra Flash memory for CoS: …. bigger troubleshooting log and 2 more languages – Arabic, Urdu” “As customer internal support tech I want 10GB extra Flash memory to load Conditions of Satisfaction: 2 more languages – Arabic, …. Urdu.” CoS: …. 22 11
- 12. 9/10/11 Splitting stories (continued) Always split Story initially by time if applicable EARLY LATER “As a developer I want 10GB “As customer internal support extra Flash memory for tech I want 10GB extra Flash bigger troubleshooting log.” memory to load 2 more CoS: languages – Arabic, Urdu.” All bits pass R-W test CoS: No cut traces on board 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. 23 Splitting stories (continued) Don’t end up with 20GB extra Flash! EARLY LATER “As a developer I want 10GB “As customer internal support extra Flash memory for tech I want 10GB extra Flash bigger troubleshooting log.” memory to load 2 more CoS: languages – Arabic, Urdu.” All bits pass R-W test CoS: No cut traces on board All screens use Arabic, Urdu Keypad allows lang. symbols Can select Arabic, Urdu Second Story merely uses the additional memory – doesn’t add any. 24 12
- 13. 9/10/11 8 Storycrafting Techniques Context matters Stories evolve Use language of project community Find the first customer Find the Conditions of Satisfaction Customer shadows Building-block stories for customer layers Do-er role 25 Splitting stories (continued) Development Field trials Cust. delivery Time Now you can Extra position Extra Flash for languages for supporting developer support tech Stories “Upgrade “Prep “Language board” translations” uploader” 26 13
- 14. 9/10/11 Customer shadows Second customer’s needs may be fully covered within those of first customer If so, one Story does it all. Else need 2 Stories 27 Customer shadows example Software developer = 1st customer Customer internal support tech = 2nd customer 2nd story only needs to address what the 1st story didn’t 2nd Story 1st Story 28 14
- 15. 9/10/11 8 Storycrafting Techniques Context matters Stories evolve Use language of project community Find the first customer Find the Conditions of Satisfaction Customer shadows Building-block stories for customer layers Do-er role 29 Extending the Story Form Some modest extensions help when building embedded applications They are not exclusive to embedded work First, a look at the problem we’re addressing 30 15
- 16. 9/10/11 The Problem… ? ? ? ? ? Time PROJECT First Release START 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? 31 Deliver in Working Increments One iteration Many Iterations A given story might not GUI slice through all APP architectural layers LIB Often necessary to keep OS stories small enough. FIRMWARE BOARD Use ‘spike’ stories when possible. 32 16
- 17. 9/10/11 Layers of Customers First iterations serve “near” customers… Prototype s/w trouble- assembly Mechanical shooters people engineers Self Algorithm Regulators, S/W Team designers Sensor Partners, Suppliers, designers Hospital adm, Electrical Physicians, Building a Patients engineers Electrical blood analyzer engineers Electrical engineers 33 8 Storycrafting Techniques Context matters Stories evolve Use language of project community Find the first customer Find the Conditions of Satisfaction Customer shadows Building-block stories for customer layers Do-er role 34 17
- 18. 9/10/11 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. ) 35 An Embedded Story Customer As a Software Developer I want Do-er an extra I/O pin brought out so that I can monitor task entry/ exit on the oscilloscope ? The Do-er is implied by which Backlog Why the Story is in. What 36 18
- 19. 9/10/11 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 What Why This way all stories could go into one Backlog. 37 S/W is Customer of H/W “Volt Mon” Story Customer As a Software Developer I want an extra I/O pin brought out so that Do-er I can monitor voltage level A/D counts on test point 3A H/W Conditions of satisfaction: I can easily get a probe onto the pin Pin is accessible with cover on 38 19
- 20. 9/10/11 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 Do-er I don’t have to open the unit in the field to check it. Conditions of satisfaction: S/W Value is displayed when * key pressed, in test mode Value is in volts Displayed value updates within 0.1 sec of change to actual 39 Customer layers & story paths “Volt Mon” MEs Algorithm EEs designers S/W Self Team 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. 40 20
- 21. 9/10/11 8 Storycrafting Techniques Context matters Stories evolve Use language of project community Find the first customer Find the Conditions of Satisfaction Customer shadows Building-block stories for customer layers Do-er role 41 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! 42 21
- 22. 9/10/11 Early Stage Stories Early workstream make-up may be dominated by building-block stories Soon gives way to mainly User stories Workstream User stories carry business value Building- block Time stories carry no business value 43 Product Evolution via Stories All these evolve as a side-effect when the voices of Customer and Engineering bring a Story to maturity. What to build Estimate Agile Story Architecture Risk Plans Test Approach QA Approach 44 22
- 23. 9/10/11 Reaching the goal Minimum Marketable Reach your project goals… Feature-set M1 M2 M3 “Now” £ By taking each story through the states from Idea to Done Idea Coarse Ready to Done Estimate build Communications about WHAT to build Communications about HOW to build 45 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 46 23
- 24. 9/10/11 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: [email protected] More info at: http://www.leanagilepartners.com/publications.html 47 24