Presentation on theme: "Agile Project Management"— Presentation transcript:
1 Agile Project Management L e a d i n g C h a n g e T h r o u g h C o l l a b o r a t i o nAgile Project Management
2 Pollyanna Pixton Founder, Accelinnova President, Evolutionary Systems L e a d i n g C h a n g e T h r o u g h C o l l a b o r a t i o nPollyanna PixtonFounder, AccelinnovaPresident, Evolutionary SystemsDirector Institute of Collaborative Leadership
3 Agenda What is Agile Agile Methods Scrum Deep Dive Estimating and PlanningGetting StartedLeading Agile
5 “Find your joy in something finished, and not a thousand things begun - Douglas Mallock5
6 Project Methods Waterfall: New Methods: Function Definition, Design, Build, CheckFunctionsDesignBuildNew Methods:Single Cycle Review and AdjustSpiral: Multiple Cycles of WaterfallAgile: Adapt As You Go: Short IterationsCheckDone
7 What is Agile?From recognition and acceptance of increasing levels of unpredictability in our turbulent economyA chaordic perspectiveCollaborative values and principlesBarely sufficient methodology- Jim Highsmith
8 Agile Encourages Mid Course Corrections Zone of successPlanned CompletionIncreasing KnowledgePlanned PathStartActual PathAs Knowledge increases Leaders use iterations to guide project towards enhanced goalAgile allows you to steer the project through mid course corrections.It’s never possible to plan perfectly. Agile (with stakeholder feedback) Iterations give you a way to compensate for the lack of perfect information during initial planning.As Eisenhower said “Planning is essential. The Plan is worthless.”Actual Completion8888
9 Business Driven – Faster & More Rewarding TimeCostProfitInvestmentBreakevenSingleReleaseSelf-FundingSoftware by Numbers by Mark Denne and Jane Cleland-HuangStagedReleasesAgile projects have a break-even point earlier in time than a traditional waterfall project for applications of the same size.Agile projects are more flexible. Can be stopped or restructured without losing all value.
11 uses continuous stakeholder feedback Many terms are used for use cases/user stories/storypoints – bottom line, effective understanding of how end users will use the software/features and what gets tested to meet the high quality consumable code piece of the definition.Iterative development – who has shipped a product recently? What release criteria was supposed to be addressed/ did you meet that criteria?Criteria should be criteria you grow into with each iteration (2 wk iterations right?)Jeff Sutherland – adds additional criteria to his releases **** must be deployed in a clients production environment, he does this in 1 week iterations but it took him 4 years to get to this point.
12 insiders principles end users partners uses continuous stakeholder feedbackprinciplesend userspartnersinsidersCarl Kessler and John Sweitzer, Outside-in DevelopmentMany terms are used for use cases/user stories/storypoints – bottom line, effective understanding of how end users will use the software/features and what gets tested to meet the high quality consumable code piece of the definition.Iterative development – who has shipped a product recently? What release criteria was supposed to be addressed/ did you meet that criteria?Criteria should be criteria you grow into with each iteration (2 wk iterations right?)Jeff Sutherland – adds additional criteria to his releases **** must be deployed in a clients production environment, he does this in 1 week iterations but it took him 4 years to get to this point.
13 …to deliver high quality, consumable working code/features
15 …and a series of short, stable, time-boxed iterations. Many terms are used for use cases/user stories/storypoints – bottom line, effective understanding of how end users will use the software/features and what gets tested to meet the high quality consumable code piece of the definition.Iterative development – who has shipped a product recently? What release criteria was supposed to be addressed/ did you meet that criteria?Criteria should be criteria you grow into with each iteration (2 wk iterations right?)Jeff Sutherland – adds additional criteria to his releases **** must be deployed in a clients production environment, he does this in 1 week iterations but it took him 4 years to get to this point.
16 Agile Defined…Uses continuous stakeholder feedback to deliver high-quality, consumable code through user stories and a series of short, stable, time-boxed iterations.
17 What is Agile?A development process that conforms to the values and principles of the Agile Alliance (agilealliance.org)Originally for software development
18 Agile ManifestoWhile there is value in the items on the right we value the items on the left more.Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
19 Agile OverviewAgile:Iterative and Incremental to deliver working softwareLight-WeightMeets Changing Needs of StakeholdersHighly Collaborative: Involves CustomersMinimizes DocumentationTest First
22 Light WeightUtilize only practices that make sense for the project and environment“Barely sufficient” artifacts, methodology, and documentation“Appropriate” vs “Best Practices”
23 Practice Excellence Requires self discipline to improved quality Relies on the team to practice technical excellence instead of imposing disciplineAdopt technical practices that support the other practices such as:Continuous IntegrationTest Driven DevelopmentRefactoring
24 Reflect and Adapt Learn from past to improve performance Retrospectives after each iterationHarness change for improved efficiencyMulti-Horizon planning allows adaptation
25 Key Characteristics of Successful Agile Projects Short, Stable, Time-Boxed IterationsStakeholder FeedbackSelf-Directed TeamsSustainable PaceBring the points previously together to review these characteristics…Ask everyone their perspective around iteration (what is it, how long is it) – Ted likes to promote the idea of 2 week iterations but the class may pick a different length.The first two features are critical towards achieving stable consumable code, the last two features focus on developing/identifying how the team works together and in what fashion.You can choose to discuss what the difference is with self-directed vs self-motivated teams? What are the terms and what do they mean. The term self- directed is intended to promote motivation
26 The Process Pendulum Code and Fix Agile Waterfall No Process Empirical PrescriptiveI LOVE this!!!!!!!EmpiricalFrequent inspectionCollaborationAdaptive responsesPrescriptiveDefined set of steps to followPlan the work, work the planPlan is assumed to be correct
27 Project Definition and Iterations Completed Deliverables Project MethodsEnvisionIterate:PlanImplementDone?AdaptCompleteProject Definition and IterationsPlanningReview and AdjustImplementDone?NOYESCompleted Deliverables
29 How Does Agile Work?“Requirements” called features, defined using user stories: As a <user/role> …I want to <goal> …so that <value>.
30 Agile ‘Process’ User stories listed in a backlog. Backlog prioritized based on value.Highest priorities estimated and grouped into an iteration (sprint), two weeks long.At end of iteration, ask if enough value to go to market?Add any new user stories to backlog and reprioritize and select next iteration/sprint.
31 Agile ‘Process’Test cases are written first, before anything is developedGo/no-go decisions reached early and often
32 Agile MUST be Disciplined Agile development necessitates greater discipline than traditional methods. “Quality” and “Consumability” must be real, not platitudes.This is a highly-disciplined activityConsumability = Capability, Usability , Performance, Maintainability, Documentation, Customer Satisfaction, High QualityAll describe the “consumability” of software.The diagram is called the Triple Constraint – (a PM term) the notion is that if cost is constant then we could potentially move the little balls and ultimately something might have to change… so to increase function, we lose quality, if we need to focus on speed to market, then quality and functionality will be affected. The point is that in adopting agile, all three of these things aren’t constrained any more.
33 “It is a bad plan that admits to no modifications. ” “It is a bad plan that admits to no modifications.” Publius Syrus (ca. 42 BCE)Project Management
39 Agile MethodseXtreme Programming, XP (Kent Beck, Ron Jeffries, Ward Cunningham)Scrum (Jeff Sutherland, Ken Schwaber, Mike Beedle)Feature Driven Development, FDD (Peter Coad, Jeff DeLuca)Crystal Methods (Alistair Cockburn)Dynamic Systems Development Method, DSDM (DSDM Consortium)Lean Development (Bob Charette, Mary and Tom Poppendieck)
40 Agile Overview“Agile projects succeed when the team gets the spirit of agility.” – Ron Jeffries, XP Thought Leader
42 XP Values and Principles CommunicationSimplicityFeedbackCourageQuality Work
43 XP Practices The Planning Game Small Releases Metaphor Simple Design RefactoringTest-First Development
44 XP Practices Pair Programming Collective Ownership Continuous IntegrationSustainable PaceOn Site CustomerCoding Standards
45 XP Roles The Customer The Developer The Tracker The Coach Sets project goals and makes business decisionsThe DeveloperTurn customer stories into working codeThe TrackerKeeps track of any metrics used by teamThe CoachGuides and mentors team
47 Scrum Roles Scrum Team Scrum Master Product Owner Carries water and moves bouldersProduct OwnerResponsible for maintaining product backlog
48 Scrum Control Points Meetings: Sprint Planning Daily Scrum Sprint Review (retrospectives and demo)
49 Feature Driven Development (FDD) Model-driven short-iteration process that consists of five basic activities:DevelopModelBuildFeatureListPlan ByFeatureDesign byFeatureBuild ByFeatureDeploy- Jeff deLuca, 1997
51 FDD Roles Chief Programmers Class owner Feature teams Team lead, mentor, developerClass ownerDeveloper with responsibility for a classFeature teamsTemporary groups of developers formed around classes
53 Crystal Clear“The team can reduce intermediate work products as it produces running code more frequently, as it uses richer communication channels between people.”- Alistair Cockburn
54 Crystal Clear“Every product is slightly different and evolves over time, so the methodology, the set of conventions the team adopts, must be tuned and evolve.”- Alistair Cockburn
55 Crystal Clear Roles Sponsor: Allocates money for the project Expert UserLead DesignerLead Technical person, mentors less experienced team membersDesigner-ProgrammerEach person designs and programs
56 DSDM Active user involvement Teams empowered to make decisions Frequent delivery of productsFitness for business purposeIterative and incremental deliveryAll changes reversibleTesting throughout lifecycleCollaboration with all stakeholders
58 Lean ManufacturingOptimizing production through removal of waste and improving flowA process management philosophy based on Toyota Production System (TPS)Focus effort on producing value- added featuresJust in time delivery
59 Lean Software Development Everything not adding value to customer is waste includes:Unnecessary code and featuresDelay in developmentUnclear requirementsBureaucracySlow internal communicationsBy Mary and Tom Poppendieck
60 Project Management Agile Project Management: The PM is the person who facilitates the team's work, removes obstacles, manages risks, and explains to management what is going on. Good PMs are on the side of the team, because that's how the product gets delivered. The ScrumMaster facilitates the team's process and removes obstacles for the team.
61 Project Management Agile Project Management: Following the values and principles of the Declaration of Interdependence (DOI)Written by the founders of the Agile Project Leadership Network (apln.org)
62 Declaration of Interdependence Continuous flow of valueEngage customersCreate an environment where individuals can make a differenceExpect uncertainty and manage for itContext specific strategies, processes, and practicesGroup accountability
65 Project StatisticsStandish Group Study, reported by CEO Jim Johnson, CIO.com, ‘How to Spot a Failing Project’
66 Project Statistics Improvements Due To Better: Tools Project Managers Adaptive MethodsBreaking projects into small chunksDelivering pieces faster for user feedback
67 Standish Group Study, reported by CEO Jim Johnson, XP2002 Never or Rarely Used: 64%Always or Often Used: 20%Rarely19%Sometimes16%Often13%Never45%Does this help us realize that we often over-engineer our designs?The Never and Rarely used not only represent our over-investing in some features and functions, that work might have kept us from developing features and functions that would help us win in the marketplace.Google Docs are competing with MS by only implementing the elements of MS Office that people actually use.Always7%Standish Group Study, reported by CEO Jim Johnson, XP2002
68 Failures Main Reasons For Project Failure : Lack of end user involvementPoor requirementsUnrealistic schedulesInadequate change controlLack of testingInflexible processes
69 Success Factors User involvement Management support Clear vision & objectivesProper planningRealistic expectationsSmaller milestonesCompetent staffOwnership
70 Challenges Deliver the right product Meet customer’s changing needs Deliver to rapidly moving market windowsInnovate on both sides of your business modelGet more done by doing lessLead in the marketplace
71 Companies Must… Deliver Business Value Increase Productivity Lead ChangeFind SolutionsInnovate
76 Scrum on a Page Roles Artifacts Meetings Stakeholders Product Owner Scrum MasterTeamProductBacklogReleaseBacklogSprintBacklogBlocksListInformation RadiatorArtifactsRelease PlanMeetingSprint PlanMeetingDailyScrumSprint ReviewMeetingMeetingsConcept inspired by William Wake’s “Scrum on a Page,”
78 StakeholdersAnyone that can give input to the business objectives of the product.
79 Types of Stakeholders Principals End Users Partners Insiders Stakeholders who champion the need for your software and have the authority to acquire and deploy it.End UsersStakeholders who personally interact with your software.PartnersStakeholders who make your product work in real life, such as operations teams and also business partners and system integrators.InsidersStakeholders within your own organization; such as developers, support engineers, sales, architecture, and marketing teams.
80 “The customer is always moving, changing, and if you’re not out there all the time trying to understand the functional and emotional needs of consumers, your design will simply fall flat.- Matthew May“Consider this quote… what is your reaction to reading this? Is it true? Do you feel its an exaggeration? Have you had instances where your customers HAVE changed and the product was too late?
81 Outside-in development is a set of principles that focus teams on developing software which helps stakeholders be successful in their business.Problem: Solutions don’t work as imagined.Cause: The facts aren’t clearly understood.Solution: Learn to see.Goal: Get inside the [stakeholder’s] mind.Understanding Your StakeholdersAligning with stakeholder goalsDefining Success in Your Stakeholders’ TermMaking Products ConsumableUnderstanding Organizational ContextOutside-In Software Development
82 I can’t imagine a world without Your productNot only could Iimagine a worldwithout it, I longFor itIt usually doeswhat we want,if painfully attimesWithout it, ourbusiness wouldsuffer, and Iwould feel asense ofpersonal loss““You know you’re lean when: customers pull compelling value from you effortlessly.One of “the eleven questions making up [the Gallup Organization’s] ‘Customer Engagement’ survey,” as cited by Matthew May, The Elegant Solution (New York: Free Press, 2007), 126. Quote from page 182.
83 Product OwnerPrioritizes backlog in collaboration with …
84 Scrum MasterRemoves the barriers between development and the customer so the customer directly drives developmentFacilitates creativity and empowermentImproving the productivity of the development team in any way possibleImproving the engineering practices and tools so each sprint is ready to deploy
85 Scrum Master Is not the project manager Team manages itselfDoesn’t have authority over the teamTeam makes decisionsAlways asks the question:“How are the Product Owner and Team doing?”Challenges the organization, key-role in the changeHowever, a dead scrum master is a useless scrum master
86 TeamTeamsAdd self organizing and ownership bits here.
88 Quick Exercise (A) Form pairs Assign one as boss, the other as worker The boss can give the following commands: Go, Stop, Right, Left, Faster, SlowerThe worker must follow the boss’s commandsGoal: 60 steps in two minutesThe boss can command the worker but not touch the workerLets test this theory shall we?Tell everyone to pair up (into groups of 3 if there are odd number of people)…. Determine who is the boss and who is the workersGet workers to raise their hands and then tell them to ignore the next set of instructions.Bosses, they have 6 words (Stop, Go, Left, Right, Backup, ?) they can use and they have to stay within the bounds of the masking tape, they have to direct the worker to take 60 steps in 2 minutes without crossing the line. Once you have reached 60 steps, stop and raise your hands…The facilitators walk around the room and keep people in the boundaries as well as tell them when then need to start over. Also observe the behaviors and approaches used.Summary discussion – ask the audiences their perspectives… what was it like? Managers typically blame the workers, workers say it was easy… almost everyone “crossed the line”… many workers actually used initiative and stopped at the line without anyone telling them to stop. How much is this like sometimes how work goes?
89 Quick Exercise (B)Everyone is a worker and responsible for figuring out how to proceed during the exerciseGoal: 60 steps in two minutesThis time, everyone does this themselves… no bosses only workers, and cut it to one minute if you want to do this quickly. The concept is very obviously achieved … the difference between Exercise 1 and this one.Typically they are MUCH quieter… and they move more quickly…Ask the audience to remark on this exercise… Was it chaotic? Confusing?So apparently the concept of self-direction seems to have merit, right? If we can assume we hire intelligent people? What would be the role of the manager then?
90 “Self-directed” or “Self organizing” Teams The concepts of leadership, management, and team involvement are prospectively very differentEncouraging a collaborative environmentAll roles support one anotherInterpretation of self-management = belief that no one is really working their hardest… this quote came from a previous class that upper management really has a hard time letting people self manage.
91 example: self-organizing teams: 3M No rainbow. Something that reps BV.
92 The “Whole Team” Concept Coders/programmersID/WritersProduct ChampionArchitectDesignerProduct OwnerProject ManagersTestersOther Roles
93 Create a Trusting Environment “When you're in a ‘trusted’ environment, teams tend to innovate better, more quickly and overall transaction costs are much lower.“As a team what are you doing to create/contribute to such an environment?Can I describe what such an environment might look like? Feel like?How do I help promote and sustain my team better?Am I helping eliminate waste or am I contributing to wasteful activities or an untrustworthy environment?
94 Create a Trusting Environment “When you're in a ‘trusted’ environment, teams tend to innovate better, more quickly and overall transaction costs are much lower.“As a team what are you doing to create/contribute to such an environment?Can I describe what such an environment might look like? Feel like?How do I help promote and sustain my team better?Am I helping eliminate waste or am I contributing to wasteful activities or an untrustworthy environment?Sue McKinneyVP MSM DevelopmentPitney Bowes
95 Trust/Ownership Model FailureNo One CaresEnergy & InnovationTeam TrustedTeam AccountableLeader FreedHow do we get here?& Business ProcessLeadershipCommand & ControlTeam Does as InstructedNo OwnershipLeader / Processis BottleneckConflictTeam DemotivatedMired in Bureaucracy& Wasted EffortControlLowTeam/Individual OwnershipHigh
96 What Does a Trust Environment Feel Like? Leader’s ViewThe team won't let me downThe team understands what we needThey will do the right thingThey will tell me if they need help
97 What Does a Trust Environment Feel Like? Individual within the TeamWe understand the vision and the needWe are jointly committed to meeting our goalsWe stand or fall togetherWe have Ownership
98 Self-directed teams: Is this lunacy? Two principles supporting the Agile Manifesto:Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.The best architectures, requirements, and designs emerge from self-organizing teams.The industry agile manifesto strongly reinforces the concept of self-organizing teams and empowering the individual.
100 Roles in a Nut ShellStakeholders: gives input as to the product business objectivesProduct owner: responsible for the business value of the projectScrumMaster: ensures that the team is functional and productiveTeam: self-organizes to get the work done
102 Product Backlog The current view of the requirements Consists of Epic User StoriesPrioritised by the Product Owner in collaboration with StakeholdersPrioritized based on Business Value and Risk
103 Release Backlog Each Release has a theme Release Backlog contains the User Stories for that releaseMade up of User Stories (broken down Epic User Stories)
104 Sprint Backlog Each Sprint has a goal Team agrees on goal and commits to itUser Stories for the Sprint
105 Blocks List Internal – Actions within the team External – Actions beyond the teamUpdated by the Scrum MasterScrum Master resolves them with team
106 Information Radiator Visual representation of progress Display of: Work Planned (Product, Release and Sprint)Work in ProgressWork DoneUser Stories to mitigate riskUser Stories to gather information to make future decisions
107 Burndown ChartPart of the Information Radiator
110 Artifacts SummaryProduct backlog: prioritized list of desired project outcomes/features (epic user stories)Release Backlog: prioritized list of user stories for the releaseSprint backlog: set of work from the product backlog that the team agrees to complete in a sprintInformation Radiator: at-a-glance look at the work progress
112 Sprint Planning Meeting At the beginning of a new SprintChaired by the Scrum MasterAttended by all including Key StakeholdersUpdate the Product Backlog with new requirementsSelect highest priority items in the backlog based on Business ValueDefine the Sprint Goal
113 Daily Scrums Daily 15 minute status meeting Same place and time every dayChaired by Scrum MasterAttended by entire sprint teamOthers can attendChickens and pigs (only the deliverers speak)
114 Daily Scrums Each team member answers: What did you do yesterday? What are you doing today?What are your blocking issues?No problem solving!Leave after 15 minutes!
115 Daily Scrum Records Sprint Backlog up to date Scrum Master updates the blocks list
116 Sprint Review Meeting Held the last day of the sprint Attended by team Team demos “done” user stories to stakeholdersRequests feedbackTeam holds retrospectiveUpdates the process for the next sprint
117 Demonstration Only DONE working user stories. Ask for attendance from the following for the first 4 iterations as numbered:ExecutiveInternal usersStakeholdersCustomers
119 Team Defines of “Done” Consider: No showstoppers All errors that the team has not agreed to are removedCode is unit tested, function tested, system tested, performance tested, tested end-to-endA meaningful stakeholder review has been conducted
120 Team Defines of “Done”Can this really be done? This puts a high premium on:Valuable, maintained, nested automationAppropriate coverage (e.g. 80%)True test-driven developmentAvoiding technical debtContinuous integrationReally understanding what quality looks like
121 Example “It took us four years to get done, done, done, done.” Jeff Sutherland (co-creator of Scrum), said PatientKeeper:“It took us four years to get done, done, done, done.”Patientkeeper provides safety critical patient management software
122 Example What does “Done”, “Done”, “Done” mean? It is fully developed It is fully testedIt has no Severity 1s or 2sIt has been deployed before a release in a client environment
123 ExampleThey shipA major release every 3 monthsA minor release every monthAnd minor updates once a weekConsider the competitors, teams of developers and they cannot achieve the work flow Patientkeeper does.
126 Scrum Meetings Summary Sprint planning: team and product owner choose work to deliver during a sprintDaily scrum: team meets each day to share struggles and progressSprint reviews: team demonstrates what completed during the sprintSprint retrospectives: team discusses ways to improve product and process.
128 Develop a Brochure in a 3 day Sprint Complete Sprint Planning Meeting -10minSelect at least 5 Product Backlog ItemsIdentify 2 to 3 Tasks per ItemDay 18 minute dayDay 22 minute Daily Scrum MeetingDay 3Demo & Reflection0004030205010610090708020003010608040705000201020100030408070605000201020100030508070604
130 Scrum on a Page Roles Artifacts Meetings Stakeholders Product Owner Scrum MasterTeamProductBacklogReleaseBacklogSprintBacklogBlocksListInformation RadiatorArtifactsRelease PlanMeetingSprint PlanMeetingDailyScrumSprint ReviewMeetingMeetingsConcept inspired by William Wake’s “Scrum on a Page,”
131 Scrum Best Practices Test Driven Development Pair testers and developersContinuous Integration
132 References http://scrumalliance.org/pages/ what_is_scrum scrum_student_resourcesThe Elegant Solution, Matthew MayOutside-in Software Development, Carl Kessler and John Sweitzer
133 References Agile Project Management with Scrum, Ken Schwaber Agile Software Development with Scrum, Ken Schwaber and Mike Beedle
137 Leading AgileUser Story BasicsCollaboration ModelCollaboration Process
138 What is a User Story?A concise, written description of a piece of functionality that will be valuable to a stakeholder. As a <role>, I can <goal> so that <business value>
139 User Story RolesAs a <role>, I want to <goal> so that I can <business value>Avoid “the user” as different stakeholders have different needsM. Cohn recommends using roles so that you do not “miss” storiesTeams can develop a set of user roles to help define relevant storiesOID is “Outside-in-development”
140 User Story Goals Goal is “what the role can do” As a <role>, I want to <goal> so that I can <business value>Goal is “what the role can do”Valuable to a stakeholderDoesn't say “how”, but “what”
141 User Story Business Value As a <role>, I want to <goal> so that I can <business value>Justifies the value of the storyClarifies why a feature is usefulCan influence how a feature should functionHelps prioritize the story in the backlogCan lead to other useful features that support the user’s goals
142 Example As an < astronaut > I can < write easily while in Zero gravity >So that < I can record key information that I might otherwise forget >
143 ExampleNASA specified and developed, at great expense, a ball point pen that Apollo astronauts could use in space where gravity would not make the ink flow. Russian cosmonauts used pencils.Moral: specify what you want to achieve, not how to achieve it
144 ExerciseAt your table, build three user stories
145 Why use User Stories?Right size for planning, works for iterative developmentDefer detail until you have the best understanding you are going to have about what you really needFocus on user goals rather than feature attributes
146 Why use User Stories?Emphasize verbal rather than written communicationPotentially fixes issues with “vague requirements”Comprehensible by both stakeholders and the development teamStories support evolutionary development
147 Where User Stories Help Value to StakeholdersStories target functionality valuable to stakeholdersStory demos each iteration engage stakeholdersIn waterfall, you run the risk of designing and coding for a long time before integration and test. A failed design is discovered months later in many cases and is much harder to fix.
148 Where User Stories Help Simplified FeaturesStories enable light-weight requirements gathering, progressive discoveryStories focus on feature essentialsIn waterfall, you run the risk of designing and coding for a long time before integration and test. A failed design is discovered months later in many cases and is much harder to fix.
149 Where User Stories Help Release PredictabilityStories by definition fit in time-boxed iterationStories that fail in an iteration provide early warning systemCadence of story completion over multiple iterations will demonstrate release predictabilityIn waterfall, you run the risk of designing and coding for a long time before integration and test. A failed design is discovered months later in many cases and is much harder to fix.
150 Leading AgileCreating User StoriesCollaboration ModelCollaboration Process
151 Release Themes Release themes are based on business objectives A well known release theme is critical to team successThemes should embody highest business value needs of the stakeholders and the product
152 Release Themes Focus on stakeholder success Focus on product welfare: reduce technical debt, increase maintainability, etc.Provide a common goal for the “whole team”Prioritize and de-prioritize work
153 Epic User StoriesEpic User Stories capture stakeholder goals for release themes.Epic User Stories fit into releasesWill not likely fit in an iterationTeam has an idea of how large the effort isProduct backlog contains Epic User StoriesCreate Epic User Stories with StakeholdersThis is the product backlog.
154 Creating User StoriesDon’t focus only on the end-user role. Consider other stakeholder types as well.PrincipalsStakeholders who champion the need for your software and have the authority to acquire and deploy it.End UsersStakeholders who personally interact with your software.PartnersStakeholders who make your product work in real life, such as operations teams and also business partners and system integrators.InsidersStakeholders within your own organization; such as developers, support engineers, sales, architecture, and marketing teams.
155 Creating Epic User Stories Insiders:As a database administratorI can back up a databaseSo that the data can be recovered if a failure occurs.
156 Creating Epic User Stories Insiders:As a developer,I know within 15 minutes whether the new code I checked in is integrated successfully with previous codeSo that …What is the business value for this user story?
157 Creating Epic User Stories Principals want time to value, return on investment:As a principal,I can have the software deployed and running in production less than one month after purchase,So that ….What is the business value for this user story?
158 Creating Epic User Stories Partners (business partners, support organizations...)As a support engineer,I can easily understand the levels of OS software used so that I can quickly reproduce reported failures,So that ….What is the business value for this user story?
160 Exercise At your table, pick a product Create Release Themes Create 2-3 Epic User Stories for the first/next 3 releases
161 User Story TeamCreate a User Story Team, including (but not limited to):Product OwnerStakeholdersScrum MasterCross-disciplinary Representatives from the scrum teamTechnical knowledge required
162 User Story Team Stakeholders on User Story Team Represent each important stakeholder type:PrinciplesEnd UsersPartnersInsidersIf real stakeholders are not available, assign stakeholder champions (team members)Champions get to know the stakeholder, understand their requirements
163 User Story TeamRefer to Mike Cohn’s book for details on how to form a user story team and gather epic stories.
164 User Story Team Keep team as small as possible… but not too small Identify team champion to coordinate inputAgree on success factors for releaseUse team to develop the first draft of user storiesUse appropriate team members to further re/define stories right before every iteration
165 Leading AgileRefining User StoriesCollaboration ModelCollaboration Process
166 Project Management How Do We Deliver? Breaking stories into smaller storiesHow Do We Deliver?
167 Using User Stories Break Epic User Stories into smaller User Stories Break Epics for the next one (or two) releasesUser Stories by definition fit into an iterationUser Stories from the Release BacklogAvoid user stories that are too small:When documenting the story takes longer than implementing itBugs, user interface tweaks, etc.
168 User Stories Successful iterations have multiple small stories: Smaller stories can be implemented & tested progressively throughout the iterationReduces the time between code and test
169 Who Sizes the Stories?Cross-disciplined scrum team that will deliver the storyStories are sized in "story points" – relative to one anotherBased on the team’s skillsBased on the technology they will useUse “Planning Poker” (next class module)No two scrum teams will size the story the same
170 Who Sizes the Stories? What if you cannot size a story? May need more domain knowledge, have more conversationsIf technology is unknown, use architectural spikesShort (time-bounded) iteration to learn “just enough” to proceed
172 User Stories Recommendation: Do not maintain a hierarchy of stories under an epicEasier to manage a flat list of user storiesHierarchical stories overcomplicate the backlogHard to remove smaller stories
173 Splitting on Operational Boundaries Search ScreenFirst:Basic User Interface50% of search fieldsParts of query builder that used those fieldsMessage “search found 297 matches”Second:Data display gridThird:Remaining search fieldsRemainder of query builderFieldsQueryBuilderComplex DataDisplay GridData-base
174 Splitting into separate CRUD operations CREATEREADUPDATEDELETEAs a technical marketing rep, I can add (create) an orderable part to the online catalogAs a technical marketing rep, I can view (read) the list of orderable parts in the online catalogAs a technical marketing rep, I can edit (update) an orderable part in the online catalogAs a technical marketing rep, I can remove (delete) orderable parts from the online catalog
175 Remove Cross-Cutting Concerns Consider creating two versions of the story: One that meets cross-cutting concerns and one that does not.Cross-cutting concerns:SecurityLoggingError handlingEtc.
176 Attributes of a Good User Story INVEST ( From Mike Cohn)AttributeExplanationIndependentDoes not depend on other storiesNegotiableNot all details necessaryValuableHas tangible value to stakeholders of the softwareEstimate-ableYou can estimate stories via story pointsSmallFits in an iteration by definitionTestableRequired to demonstrate that story is “done”
177 ExerciseBreak your Epic User Stories for the first release into User Stories.Do they all have the attributes of a good user story (INVEST)?
178 Leading AgileUser Stories FlowCollaboration ModelCollaboration Process
179 Demo Working Code to Stakeholders Flow: The Big PictureEpicsStoriesReleasePlanningTrawl forRequirementsStakeholderGoalsCreate/sizeUserStoriesRelease BacklogEpicsStoriesIteration BacklogSelectHigh-priorityStoriesReflect& Take ActionTime Boxed IterationGet FeedbackRefine Stories,Plan WorkScrumCode, Doc & TestDiscuss Story ProgressDemo Working Code to Stakeholders
180 Evolutionary Feature Design Why not stick to well defined features documented in the beginning of the release?Once users see a feature start to work, they better understand how they want to use the featureFeature design & functionality will adapt to what becomes possible in the technology as you use it & learn about itRelease priorities, market forces, and stakeholder needs change throughout the life of the productTeam members learn from stakeholders as they goThis is one of the biggest issues that many waterfall developers have with moving to Agile. It feels easier to implement something that does not change.Feature design has to evolve as you use the technology and learn about itFunctionality will have to adapt to what becomes possible in the technologyFeature design and functionality will adapt to what you learn about the technology as you use itFrom Mike Cohns, User Stores, and Kessler, Sweitzer Outside-In Software DevelopmentOld sub-bulletsIn other words they change their minds about what they want once they see it workingAssumptions made at the beginning of the development cycle may be jeopardizedPlan for this, allow products to evolve as they are developed
181 Evolutionary Design: How it can work User Stories SummaryMap content released functionality iteratively1: Input an address and see the location on a street map2: Input two addresses and get directions between them3: Change the route by dragging the route to other streetsIf this feature was fully specified in the beginning, how would it look?How would you specify alternate routes? Using current traffic? Listing the other roads to use?Once you see the route, it seems obvious to want to drag itLessons? Evolutionary feature design workedGet “enough” functionality out soonerDiscover what feature to add next based on feedbackThe point is you do not have all the features you may want like a route by traffic, a bike-friendly route, comparison of routes, etc. But as you add useful features, the feedback they get will help them determine what to do next.Jun/10
187 Key Characteristics of Successful Agile Projects Short, Stable, Time-Boxed IterationsStakeholder FeedbackSelf-Directed TeamsSustainable PaceBring the points previously together to review these characteristics…Ask everyone their perspective around iteration (what is it, how long is it) – Ted likes to promote the idea of 2 week iterations but the class may pick a different length.The first two features are critical towards achieving stable consumable code, the last two features focus on developing/identifying how the team works together and in what fashion.You can choose to discuss what the difference is with self-directed vs self-motivated teams? What are the terms and what do they mean. The term self- directed is intended to promote motivation
189 Project Framework - Iteration Plan InceptionElaborationConstructionTransitionProduct-ionArchitectural “Spikes”Prototypingconsumability tasksglobalization and translation focusAMDD – Agile Model Driven Development (integration with other components / products
191 Framework - Overlapping Releases InceptionElaborationConstructionTransitionProduct-ionInceptionElaborationWarning: Beware of PowerPoint ArchitectsSee Andy Hunt and Venkat Sumramaniam’s discussion on PowerPoint architects in Practices of an Agile Developer (Raleigh, NC: Pragmatic Bookshelf, 2006).