The document discusses techniques for crafting user stories that are effective for embedded software projects, noting that context is important, stories evolve over time, and it can be useful to identify the customer, what they want, why they want it, and to find the conditions of satisfaction. It also recommends considering building block stories for different technical layers and identifying the "do-er" or performer of the work in the story.

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