Embedded storycrafting

9/10/11 Embedded Storycrafting Key to controlling risk and schedule Nancy Van Schooenderwoert http://www.leanagilepartners.com/ NancyV@LeanAgilePartners.com © 2008-11 Lean-Agile Partners Inc. All rights reserved. 1Nancy 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

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

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

9/10/11 Each feature goes thru…   Features travel from ‘Idea’ to ‘Done’   Agile Story format is one way to make that happenIdea 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

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

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

9/10/11How 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 EstimateRequires mainly discussion of WHAT to build,and some discussion of HOW to build it 13Story 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

9/10/11Example 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 test3rd bullet added by Team during estimation exercise.(Handling comms faults makes the job much bigger.)Stories evolve. 158 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/10/11 Aerospace Story headlinesAero 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 intoAero 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

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, inputsRule: 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

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-shootingextra Flash memory forbigger 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 10GBextra Flash memory for CoS: ….bigger troubleshooting logand 2 more languages –Arabic, Urdu” “As customer internal support tech I want 10GB extra Flash memory to loadConditions of Satisfaction: 2 more languages – Arabic,…. Urdu.” CoS: …. 22 11

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 supportextra Flash memory for tech I want 10GB extra Flashbigger troubleshooting log.” memory to load 2 moreCoS: 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, UrduSplitting 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 supportextra Flash memory for tech I want 10GB extra Flashbigger troubleshooting log.” memory to load 2 moreCoS: 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, UrduSecond Story merely uses the additional memory – doesn’t addany. 24 12

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 TimeNow you can Extraposition Extra Flash for languages forsupporting developer support techStories “Upgrade “Prep “Language board” translations” uploader” 26 13

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

9/10/118 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 29Extending 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

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

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 Electricalblood 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

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

9/10/11 An Embedded Story (again) Customer Do-erAs a Software Developer I want EEsto bring out an extra I/O pin so thatI can monitor task entry/ exit on the oscilloscope What WhyThis way all storiescould go into oneBacklog. 37 S/W is Customer of H/W“Volt Mon” Story CustomerAs a Software Developer I wantan extra I/O pin brought out so that Do-erI can monitor voltage level A/D counts on test point 3A H/WConditions of satisfaction:  I can easily get a probe onto the pin  Pin is accessible with cover on 38 19

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

9/10/118 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 41Other 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

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 EstimateAgile Story Architecture Risk Plans Test Approach QA Approach 44 22

9/10/11 Reaching the goal Minimum MarketableReach 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

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: nancyv@leanagilepartners.com  More info at: http://www.leanagilepartners.com/publications.html 47 24

http://agileonthebeach.com	86
http://www.agileonthebeach.com	55
http://www.agileonthebeach.co.uk	3
http://cache.historious.net	1

Embedded storycrafting

by AgileOnTheBeach on Sep 21, 2011

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 145

Statistics

Embedded storycrafting Document Transcript