Agile Leadership Training

Agile Leadership Training Armond Mehrabian @armond_m Enterprise Agile Coach and Trainer CSP, PMP, SPC1

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

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

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

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

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

Building Trust Credibility + Reliability + IntimacyTrusted =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

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

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

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

The Five Dysfunctions of a Team Teamwork is the ultimate competitive advantage. But, many teams are dysfunctionalSource: Five Dysfunctions of a Team, Patrick Lencioni © 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 15

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

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

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

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

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

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

Working AgreementsWorking 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

Continuous ImprovementAgile 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

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

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

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 iterationsSource: wikipedia © 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 29

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

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

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

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

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

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

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

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

Houston, we have a problem. Houston, we have aAfter 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 PlanAnswer: e. Create a Corrective Action Plan © 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 40

Corrective Action PlanWhat is a CorrectiveAction 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

Effective Corrective Action Plans1. State the new problem (the selected root cause) succinctly2. Brainstorm a solution. Divide into discrete activities.3. Establish accountability4. Specify measurable results5. Set achievable deadlines6. Monitor progress © 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 42

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

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

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

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

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

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

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

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

User Story Card ExamplesAs 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 andenergy costs and usage retain secure passwords, keeping the system secure.As a utility Marketing Director, As a technical support member, II can present users with new want the user to receive apricing 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

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

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

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

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

ExerciseCreate 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

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

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

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

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

Starting Point Ending Point As a <user> I As a <user> Iwant <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> Iwant <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

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

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

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

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

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

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 DisplayAs a utility, I want toupdate and publish  ...I can send a message to thepricing programs to customer’s web portalmy 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

Split by Business Rule Variations Business rule variations often provide a straightforward splitting scheme ...sort by zip codeAs a utility, I can ...sort by homesort customers by demographicsdifferentdemographics... ...sort by energy consumption © 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 80

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 forpricing program my energy...with my utilitythrough my web …I want to enroll inportal... Critical-Peak-Pricing ... © 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 81

Split by Simple / Complex Simplify! What’s the simplest version that can possibly work?As a user, Ibasically want a ...respond to the timefixed price, but I and the duration of thealso want to be critical peak pricing eventnotified of Critical- ...respond to emergencyPeak-Pricing eventsevents... © 2008 - 2012 Leffingwell, LLC, Scaled Agile, Inc. and Pearson Education, Inc. All rights reserved. 82

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

Split by Use Case ScenariosIf 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 equipmentAs a user, I can enroll  Use Case/Story #2: Utilityin the energy savings provisions equipment and data,program through a notifies consumerretail 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

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

http://www.tumblr.com	9
http://www.armondmehrabian.com	7
http://pinterest.com	3
https://si0.twimg.com	2
https://twimg0-a.akamaihd.net	1
http://www.linkedin.com	1

Agile Leadership Training

by Armond Mehrabian on Jul 20, 2012

Accessibility

Categories

Upload Details

Usage Rights

6 Embeds 23

Statistics

Agile Leadership Training Presentation Transcript