Weitere ähnliche Inhalte Ähnlich wie Agile Leadership Training (20) Kürzlich hochgeladen (20) Agile Leadership Training2. Exercise – Ice Breaker
Introductions
Prepare to tell us:
– Your name
– What you’re most excited in your new role
– What you’re most anxious about
– You can also say PASS
Timebox:
10 minutes
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 2
3. Agenda
Agile Leadership
Building Trust
Building High Performance Team Members
Leading Productive Meetings
Leading Retrospectives
Leading Transformation Initiatives
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 3
4. Agile Leadership
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 4
5. Servant Leadership
“Good leaders must first become good servants”
– Robert Greenleaf, the father of Servant Leadership
A servant-leader knows that their own growth
comes from facilitating the growth of others, who
deliver the results.
Fons Trompenaars, Ed Voerman. Servant Leadership Across Cultures.
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 5
6. Exercise
Who are the two people that have influenced
your character the most?
Can be historical figure or living person
What qualities do you admire most about them?
Discuss with partner.
Timebox:
20 minutes
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 6
7. The Servant Leader:
Listens to and supports team members in decision-
identification and decision-making
Understands and empathizes with others
Encourages and supports the personal
development of each individual
Persuades, rather than uses authority
Thinks beyond day-to-day realities
Looks for where he/she could help without
diminishing others’ commitment
Builds Trust with followers
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 7
8. Building Trust
Credibility + Reliability + Intimacy
Trusted
=
Advisor Self-Orientation
Source: David Maister, Charles Green, Robert Galford. Trusted Advisor
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 8
9. Start the Chain Reaction…
Servant Leadership spreads virally “by example”. Scrum Masters ignite the
process. In turn, team members are eager to help and serve others.
Product Owner
Scrum Master
Other teams in
the program
Other SMs
in SoS
* Fons Trompenaars, Ed Voerman. Servant Leadership Across Cultures.
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 9
11. Building world-class teams
T-shaped people have
a deep interest and expertise
in one area
branch out into many different
areas of knowledge
The 10-year rule
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 11
12. Building world-class teams
Panic Zone
Learning Zone
Comfort
Zone
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 12
13. Building world-class teams
Software Engineering best practices:
• XP Practices • TDD
• Continuous • ATDD
Builds • Innovation
• Value Stream Games
Mapping • Agile artifacts
• Agile PM tools • Continuous
• Paired Deployment
Programming • Retrospectives
• Agile Metrics • Release Planning
• Pomodoro • Process maturity
method
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 13
15. The Five Dysfunctions of a Team
Teamwork is the
ultimate competitive
advantage.
But, many teams are
dysfunctional
Source: Five Dysfunctions of a Team, Patrick Lencioni
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 15
16. Identifying Trust in Teams
Conceal weaknesses and mistakes Admit weaknesses and mistakes
from one another Ask for help and accept questions
Hesitate to ask for help or offer help and input about their area of
outside their area of responsibility responsibility
Jump to conclusions about the Give one another the benefit of the
intentions and aptitudes of others doubt before arriving at a negative
without attempting to clarify them conclusion
Waste time and energy on Focus time and energy on important
managing behaviors for effect issues, not politics
Dread meetings and find reasons to Look forward to working as a group
avoid spending time together
Take risks on offering feedback
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 16
17. Building Trust in Teams
Human Resources approach
– Personal history exercise
– Team effectiveness exercise
– Personality profiles
– 360-Degree feedback
– Experiential team exercises
OR
Commit to short focused goals where you
focus on results and build trust through work
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 17
18. Scrum Master as Coach
Scrum Master behaviors become coaching behaviors when…
Moving away from Moving towards
Coordinating individual Coaching the whole team towards
contributions collaboration
Being a subject-matter expert Being a facilitator
Being invested in specific outcomes Being invested in the team’s
Knowing the answer overall performance
Directing Asking the team for the answer
Driving Letting the team find their own way
Talk of deadlines and technical Talk of business value delivery
options Talk of doing the right thing for the
Talk of doing the optimal thing business right now
Fixing problems Have the right Story, State, and
Strategy
Lyssa Adkins. Coaching Agile Teams.
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 18
19. Daily Scrum (standup) Meeting
In the Daily, 15 minute Scrum, Scrum Master helps the team
efficiently share knowledge, status and commitments.
Start at the same time every day
Timeboxed to 15 minutes max.
Run in front of a BVIR
Use simple structure:
Opening 1 min Set positive and productive tone for the meeting
Team member report 0.5 – 1.5 min The three questions
Brief discussion 0 – 1.5 min Questions, clarifications
Closing 1 min Set productive tone for the day
as much
Meet after as needed…
Discuss issues that require more time
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 19
20. Make results visible with BVIR
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 20
21. Effective Agile Meetings
Efficient face-to-face communication is facilitated by simple tools
Always have sufficient
whiteboards, flipcharts,
markers, stickies and…
camera to capture the content
“…there is a linear correlation
between design workshop
effectiveness and the amount
of whiteboard space” *
* Adapted from Larman and Vodde, “Practices for Scaling Lean & Agile Development”
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 21
22. The 3 + 1 Questions in More Depth
What did I do lately (yesterday)?
– Early story completion? Or a DBT cycle of a story?
– Completion of a known dependency?
– Resolving someone’s blocker?
– Changes in interfaces, design, or infrastructure?
– New experience, process, practice?
What I’m going to work on now (today)?
– Someone’s dependencies on me?
– My dependencies on the others?
– Expectation of early story completion, or a DBT cycle?
– Start from the end: what is the expected tangible result
What’s blocking me?
– Did I change the story/task order?
– Not a blocker but risk or difficulty or a slow-down factor?
Am I landing my piece in this iteration?
– Landing all my stories?
– All fully implemented, tested, deployed, etc?
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 22
23. Working Agreements
Working agreements facilitate conflict management. Have them. Keep them
visible.
As a participant on this team, I agree and
acknowledge that:
I am committed to the team’s objectives and
goals
I respect other people opinions, even when they
contradict or conflict with mine
If we cannot reach unanimity, I will seek and
support a consensus decision
I will at all times avoid blocking my team from
moving forward
Whether or not team decision coincides with
mine, I will do my best implementing it
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 23
24. Avoid this at any cost
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 24
25. Continuous Improvement
Agile teams continuously adapts to new circumstances and improves
the methods of value delivery
Understand where you are
Foster the culture of “improving everywhere”
Use retrospectives as summary points but not
a limitation
Amplify learning
Actively engage with other SMs to drive
improvement on the program level
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 25
26. Leading Retrospectives
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 26
27. Why have a retrospective?
Without retrospectives you will find that
the team keeps making the same mistakes
over and over again.
- Henrik Kniberg, Scrum and XP from the Trenches
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 27
28. Prime Directive
"Regardless of what we discover, we
understand and truly believe that
everyone did the best job they could,
given what they knew at the time, their
skills and abilities, the resources
available, and the situation at hand.”
Norm Kerth, Project Retrospectives: A Handbook for
Team Reviews
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 28
29. Retrospectives
Focus conversations around learning and
improvements
Spend half the retrospective looking back
over the past iteration
Uncover insights about what happened and
why
Develop action plans for next iterations
Source: wikipedia
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 29
30. Exercise – Broad Retrospective
Perform a broader retrospective on
Current PSI
Create a timeline for the time horizon
Use sticky notes to describe key event during the iteration
Use colors to indicate the type of events and feelings
associated with them
Walk the timeline and try digging down to underlying causes
Choose the top 3 topics using dot voting
Prepare to present your result
Timebox:
45 minutes
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 30
31. Getting to the Root Cause
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 31
32. Root Cause Analysis Diagram
Definition: A graphic tool used to explore and
display opinion about sources of variation in a
process.
– Also called a Cause-and-Effect , Ishikawa Diagram
(who first used the technique in the 1960s.) or
Fishbone Diagram.
Purpose: To arrive at a few key sources that contribute most
significantly to the problem being examined.
– These sources are then targeted for improvement.
– Also illustrates the relationships among the wide variety of possible
contributors to the effect.
The name of a basic problem of interest is entered at the right of the
diagram at the end of the main "bone".
Source: wikipedia
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 32
33. Root Cause Analysis (Fishbone) Diagram
Our main “bones” represent typical
sources of problems in software
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 33
34. Root Cause Analysis Diagram, contd.
The main possible causes of the problem (the effect) are drawn as
bones off of the main backbone.
The starting bones represent all possible influences.
Brainstorming is typically done to add possible causes to the main
"bones" and more specific causes to the "bones" on the main
"bones".
This subdivision into ever increasing specificity continues as long as
the problem areas can be further subdivided.
The practical maximum depth of this tree is usually four or five levels.
When the fishbone is complete, one has a complete picture of all the
possibilities about what could be the root cause for the designated
problem.
Source: wikipedia
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 34
35. The 5 Why’s
The 5 Whys is a question-asking method used to explore the
cause/effect relationships underlying a particular problem.
Ultimately, the goal of applying the 5 Whys method is to determine a
root cause of a defect or problem.
A critical component of problem solving training integral to the
Toyota Production System.
The architect of the Toyota Production System, Taiichi Ohno,
(Toyota Chairman) described the 5 whys method as "... ... by
repeating why five times, the nature of the problem as well as its
solution becomes clear.”
The tool has seen widespread use beyond Toyota, and is now used
within Kaizen, lean manufacturing, and Six Sigma.
Source: wikipedia
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 35
36. Example ‒ The 5 Why’s
My car will not start. (the problem)
Why? - The battery is dead. (first why)
Why? - The alternator is not functioning. (second why)
Why? - The alternator belt has broken. (third why)
Why? - The alternator belt was well beyond its useful service life
and has never been replaced. (fourth why)
Why? - I have not been maintaining my car according to the
recommended service schedule. (fifth why, root cause)
Questioning could be taken further to a sixth, seventh, or greater level.
This would be legitimate, as the "five" in 5 Whys is not gospel; rather, it is
postulated that five iterations of asking why is generally sufficient to get to a
root cause.
The key is to avoid assumptions and logic traps
Instead trace the chain of causality in direct increments from the effect to a
root cause that still has some connection to the problem.
Source: wikipedia
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 36
37. Root Cause Analysis (Fishbone) Diagram
Cause of cause of
cause of cause 1 Cause of cause
of cause 1
Cause of
cause 1
Cause 1
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 37
38. Exercise – Root Cause Analysis
Create Your Fishbone Diagram
Succinctly state the problem you are addressing
Create a fishbone diagram for your problem statement
Brainstorm potential causes of the problem, and place them
on the chart
For each cause identified, use the 5 whys technique to get
to a potential root cause
Prepare to present your result
Timebox:
25 minutes
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 38
39. Corrective Action Plan
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 39
40. Houston, we have a problem.
Houston, we
have a
After we determine we have a problem, problem...
what’s next?
a. Ignore it - the problem may go away
b. Blame it on another team
c. Blame it on the business owner
d. Blame it on another program
e. Create a Corrective Action Plan
Answer:
e. Create a Corrective Action Plan
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 40
41. Corrective Action Plan
What is a Corrective
Action Plan anyway?
Corrective – A different course
of action
Action – Active steps we can
realistically accomplish
Plan – Organized, purposeful,
accountable, measurable
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 41
42. Effective Corrective Action Plans
1. State the new problem (the
selected root cause)
succinctly
2. Brainstorm a solution. Divide
into discrete activities.
3. Establish accountability
4. Specify measurable results
5. Set achievable deadlines
6. Monitor progress
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 42
43. Effective Corrective Action Plans
Why
Value =
How
Source: David Hussman. Dude’s Law, inspired by Ohm’s Law: I= V/R
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 43
44. Exercise – Corrective Action Plan
Build Your Corrective Action Plan
Pick the top root cause
Build a corrective action plan. This will create
your program improvement backlog items
Prepare to present your results
Timebox:
10 minutes
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 44
46. Change Management
1. Establish a sense of urgency
2. Form a powerful guiding coalition
3. Create a vision
4. Communicate the vision
5. Empower others to act on the vision
6. Create short-term wins
7. Consolidate improvements and produce more change
8. Institutionalize new approaches
John Kotter. Leading Change
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 46
47. Exercise – Ice Breaker
Introductions
Prepare to tell us:
– Your name
– What you’re most excited in your new role
– What you’re most anxious about
– You can also say PASS
Timebox:
10 minutes
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 47
48. Agenda
Driving Innovation
3Cs
Backlog Grooming
Personas
User Story Maps
Innovation Games
Estimation
User Story Splitting
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 48
49. Driving Innovation
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 49
50. Driving Innovation
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 50
51. User Stories
User Stories are a tool for elaborating backlog items
User Stories represent
customer requirements
rather than document them
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 51
52. User Story Template
The “user voice” form focuses the team on value delivery
As a <role>
I can <activity>
So that <business value>
(Roles can be people, devices, or systems)
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 52
53. User Story: The 3 C’s
Written on card Details in Acceptance
or in tool and conversation tests confirm
may annotate with product the story
with notes owner correctness
Verify that the tools
As a spouse have been put away
I want a clean Verify that items on
What about the the floor have been
garage
bikes? returned to the
so that I can park my
Oh yeah, hang the proper shelf
car and not trip on
bikes Verify that the bikes
my way to the door have been hung
3 C’s coined by Ron Jeffries
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 53
54. User Story Card Examples
As a Consumer, I want As an administrator, I can set
to be able to see my the consumer’s password
daily energy usage so security rules so that users
that I can lower my are required to create and
energy costs and usage retain secure passwords,
keeping the system secure.
As a utility Marketing Director, As a technical support member, I
I can present users with new want the user to receive a
pricing programs so that they consistent and clear message
are more likely to continue anywhere in the application so
purchasing energy from me. that they can fix the issue
without calling support.
See Agile Software Requirements by Dean Leffingwell for the Tendril case study and more examples
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 54
55. INVEST in a Good Story
INVEST acronym created by Bill Wake
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 55
56. Backlog Grooming
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 56
57. Backlog Grooming
Purpose:
– Streamline sprint planning. If done well, sprint planning
time should be cut in half
– Make user stories immediately actionable
– Gives incubation time for ideas before the team has to
commit to the sprint
Who:
– The whole team.
– Invite an SMEs as necessary.
When:
- Few days before sprint planning
How Long:
- 2 hrs. per sprint
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 57
58. What is backlog grooming
Revisit the 3Cs (Card, Conversation, Confirmation)
Add new stories
Remove stories that are no longer relevant
Estimate the effort of the highest priority stories
– Planning Poker
– Team Estimation
Split existing stories
– By Use Case
– By Simple vs. Complex
– By Acceptance criteria
Define acceptance criteria at a finer level of granularity
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 58
59. Running Effective Grooming Sessions
Have a clear goal in mind
– “Here’s the list of the user stories I would like us to focus
on”
Keep the energy level high by
– seeding ideas, mockups, customer insights
– Innovation Games and Story Maps
Take control of the meeting
– Avoid too many “What do you guys think…” statements
Gain full cooperation of Scrum Master
– to keep the conversation going
– To keep a positive and productive atmosphere
Keep the meeting under two hours
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 59
60. Pragmatic Personas
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 60
61. Persona Template
Choose a Name (Alliteration help it be sticky)
Add an image (a conversation starter)
Who is this person? What are they looking
for in the product?
•Time at the job? •Financial Benefits?
•Knowledge of domain? •Increased Productivity?
•Full time/Part time worker? •Fewer Steps?
•Incentives? •More fun?
•Level of Engagement? •Easier to Use?
•Education Level?
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 61
62. Exercise
Create a persona for your product
Who is this person and what do they want
from the product
Timebox:
15 minutes
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 62
63. Story Maps
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 63
64. Story Maps
Story Mapping is an Agile technique for
managing product backlogs developed by Jeff
Patton
They give a structure and context to user
stories.
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 64
65. Story Maps
1. Take one persona and ask “What do you do
at work every day?”
• Scenarios
• Activities
• Business Process
2. Walk “a day in the life” for each item in 1
• User tasks
• Sub Processes
3. Backup and retell the
• Are there any variations or dead-ends?
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 65
66. PSI1 PSI1 PSI2
PSI2
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 66
67. Exercise
Create a story map for your
persona
What are some tasks that they perform?
What are the sub-tasks that the system must
perform on their behalf?
What are the paths through a complete user
task.
Timebox:
10 minutes
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 67
68. Team Estimation
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 68
69. Game Play
Place Story Cards in pile on table, place top card on playing
surface
Next player places top card on playing surface relative to
first card (left easiest, right hardest)
In succession, each player can either:
– Play top card from pile (arranging under existing card or making new
column)
– Moving a card on the playing surface
– Pass
Repeat above step until:
– No more cards remain in the pile, and
– No player wishes to move a card
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 69
70. Starting Point Ending
Point
As a <user> I
As a <user> I
want <capability> I
As a <user>
want <capability> I
As a <user>
so that I get
want <capability> I
As a <user>
so that I get
want <capability> I
<value> I get
so that a <user>
As
want <capability> I
<value> I get
so that a <user>
As
want <capability> I
<value> I get
so that a <user>
As
want <capability>
<value> I get
so that
want <capability>
<value> I get
so that
<value> I get
so that
<value>
<value>
As a <user> I As a <user> I As a <user> I As a <user> I As a <user> I As a <user> I
want <capability> want <capability> want <capability> want <capability> want <capability> want <capability>
so that I get so that I get so that I get so that I get so that I get so that I get
<value> <value> <value> <value> <value> <value>
As a <user> I As a <user> I As a <user> I
want <capability> want <capability> want <capability>
so that I get so that I get so that I get
<value> <value> <value>
As a <user> I
want <capability>
so that I get
<value>
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 70
71. Start Position
Pick and place next
As a <user> I
As a <user> I
want <capability> I
As a <user>
want <capability> I
As a <user>
so that I get
want <capability> I
As a <user>
so that I get
want <capability> I
<value> I get
so that a <user>
As
card want <capability> I
<value> I get
so that a <user>
As
want <capability> I
<value> I get
so that a <user>
As
want <capability>
<value> I get
so that
want <capability>
<value> I get
so that
<value> I get
so that
<value>
Pick and place next <value>
card
Pick and place next As a <user> I
want <capability>
so that I get
card <value>
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 71
72. Keep Going
Re-prioritize card
As a <user> I
As a <user> I
want <capability> I
As a <user>
want <capability> I
As a <user>
so that I get
want <capability> I
As a <user>
so that I get
want <capability>
<value> I get
so that
want <capability>
<value> I get
so that
Pick and place next <value> I get
so that
<value>
<value>
card
As a <user> I As a <user> I As a <user> I
want <capability> want <capability> want <capability>
so that I get so that I get so that I get
<value> <value> <value>
As a <user> I
want <capability>
so that I get
<value>
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 72
73. Until Done
As a <user> I As a <user> I As a <user> I As a <user> I As a <user> I
want <capability> want <capability> want <capability> want <capability> want <capability>
so that I get so that I get so that I get so that I get so that I get
<value> <value> <value> <value> <value>
As a <user> I As a <user> I As a <user> I
want <capability> want <capability> want <capability>
so that I get so that I get so that I get
<value> <value> <value>
As a <user> I
want <capability>
so that I get
<value>
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 73
74. Then Assign Story Points
2 3 5 13 20
As a <user> I As a <user> I As a <user> I As a <user> I As a <user> I
want <capability> want <capability> want <capability> want <capability> want <capability>
so that I get so that I get so that I get so that I get so that I get
<value> <value> <value> <value> <value>
As a <user> I As a <user> I As a <user> I
want <capability> want <capability> want <capability>
so that I get so that I get so that I get
<value> <value> <value>
As a <user> I
want <capability>
so that I get
<value>
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 74
75. User Story Splitting
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 75
76. INVEST in a Good Story
INVEST acronym created by Bill Wake
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 76
77. User Stories are Small (ideally <= 8 points)
Technical Functional
Spike Spike Split Story
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 77
78. Splitting User Stories
Workflow Steps Data Methods
Business Rule Defer System
Variations Qualities
Major Effort Operations
Simple/Complex Use Case
Scenarios
Variations in Data
Break Out a Spike
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 78
79. Split by Workflow Steps
Identify specific steps that a user takes to accomplish a workflow,
then implement the workflow in increments.
...I can publish pricing programs
to the customer’s In-Home
Display
As a utility, I want to
update and publish ...I can send a message to the
pricing programs to customer’s web portal
my customer... ...I can publish the pricing table
to a customer’s smart thermostat
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 79
80. Split by Business Rule Variations
Business rule variations often provide a straightforward splitting
scheme
...sort by zip code
As a utility, I can
...sort by home
sort customers by
demographics
different
demographics... ...sort by energy
consumption
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 80
81. Split by Major Effort
Split into several parts with the first requiring the most effort.
Adding more functionality can be done later one.
As a user, I want ...I want to use Time-of-
to be able to Use pricing...
select/change my
...I want to pre-pay for
pricing program
my energy...
with my utility
through my web …I want to enroll in
portal... Critical-Peak-Pricing ...
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 81
82. Split by Simple / Complex
Simplify! What’s the simplest version that can possibly work?
As a user, I
basically want a ...respond to the time
fixed price, but I and the duration of the
also want to be critical peak pricing event
notified of Critical- ...respond to emergency
Peak-Pricing events
events...
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 82
83. Split by Operations
Split by type of operation example: Create Read Update Delete
(CRUD)…
...I can sign up for an
account.
As a user, I can ...I can edit my account
manage my account settings.
... ...I can cancel my account.
…I can add more devices to
my account
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 83
84. Split by Use Case Scenarios
If use cases are used to represent complex interaction, the story can
be split via the individual scenarios
Use Case/Story #1 (happy path):
Notify utility that consumer has
equipment
As a user, I can enroll
Use Case/Story #2: Utility
in the energy savings
provisions equipment and data,
program through a notifies consumer
retail distributor ...
Use Case/Story #3 (alternate
scenario): Handle data validation
errors
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 84
85. Split – If All Else Fails, Break out a Spike
In some cases, a story may be
hard to estimate
– may be too large or overly
complex
– or perhaps the implementation
is poorly understood Technical Functional
Spike Spike
In that case, build a technical or
functional spike to figure it out;
then split the stories based on
that result.
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 85
86. Q&A
© 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 86