Presentation is loading. Please wait.

Presentation is loading. Please wait.

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 n.

Similar presentations


Presentation on theme: "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 n."— 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 n

2 Pollyanna Pixton Founder, Accelinnova President, Evolutionary Systems Director Institute of Collaborative Leadership 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 n

3 Agenda  What is Agile  Agile Methods  Scrum Deep Dive  Estimating and Planning  Getting Started  Leading Agile

4 What is agile?

5 “Find your joy in something finished, and not a thousand things begun.” - Douglas Mallock

6 Project Methods  Waterfall:  Function Definition, Design, Build, Check Functions Design Build CheckDone  New Methods:  Single Cycle Review and Adjust  Spiral: Multiple Cycles of Waterfall  Agile: Adapt As You Go: Short Iterations

7 What is Agile? From recognition and acceptance of increasing levels of unpredictability in our turbulent economy  A chaordic perspective  Collaborative values and principles  Barely sufficient methodology - Jim Highsmith

8 8 As Knowledge increases Leaders use iterations to guide project towards enhanced goal Agile Encourages Mid Course Corrections Planned Path Actual Path Actual Completion Start Zone of success Planned Completion Increasing Knowledge

9 Business Driven – Faster & More Rewarding Agile 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. Time Cost Profit Investment Breakeven Single Release Self-Funding Breakeven Software by Numbers by Mark Denne and Jane Cleland-Huang Staged Releases

10 Agile Defined…

11 uses continuous stakeholder feedback

12 principles end users partners insiders uses continuous stakeholder feedback

13 …to deliver high quality, consumable working code/features

14 … through user stories

15 … and a series of short, stable, time- boxed iterations.

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 Manifesto While there is value in the items on the right we value the items on the left more.  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan

19 Agile Overview Agile:  Iterative and Incremental to deliver working software  Light-Weight  Meets Changing Needs of Stakeholders  Highly Collaborative: Involves Customers  Minimizes Documentation  Test First

20 Example: Legacy Highway

21 Agile Principles

22 Light Weight  Utilize 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 discipline  Adopt technical practices that support the other practices such as:  Continuous Integration  Test Driven Development  Refactoring

24 Reflect and Adapt  Learn from past to improve performance  Retrospectives after each iteration  Harness change for improved efficiency  Multi-Horizon planning allows adaptation

25 Key Characteristics of Successful Agile Projects Short, Stable, Time-Boxed Iterations Stakeholder Feedback Self-Directed Teams Sustainable Pace

26 The Process Pendulum Code and FixWaterfallAgile No ProcessPrescriptiveEmpirical  Frequent inspection  Collaboration  Adaptive responses Prescriptive  Defined set of steps to follow  Plan the work, work the plan  Plan is assumed to be correct

27 Project Methods Done? Planning Project Definition and Iterations Completed Deliverables Review and Adjust Implement  Envision  Iterate:  Plan  Implement  Done?  Adapt  Complete YES NO

28 Agile Cycles Vision Planning Develop Iteration Plan Review / Adapt Iteration Planning Iterations Plan High Level Planning Detailed Planning

29 How Does Agile Work? “Requirements” called features, defined using user stories: As a … I want to … so that.

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 developed  Go/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.

33 “It is a bad plan that admits to no modifications.” -- Publius Syrus (ca. 42 BCE) Project Management

34 What is agile Summary

35 Agile Defined… Uses continuous stakeholder feedback to deliver high-quality, consumable code through user stories and a series of short, stable, time-boxed iterations.

36 References  What Is Agile Software Development? Jim Highsmith, CrossTalk, the Journal of Defense Software Engineering  The New Methodology, Martin Fowler   Why Agile (video) si.com/fr/conferences/6/sessions/909

37 User Stories Your Questions?

38 Project Management  Remove Obstacles Agile Methodologies

39 Agile Methods  eXtreme 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

41 eXtreme Programming

42 XP Values and Principles  Communication  Simplicity  Feedback  Courage  Quality Work

43 XP Practices  The Planning Game  Small Releases  Metaphor  Simple Design  Refactoring  Test-First Development

44 XP Practices  Pair Programming  Collective Ownership  Continuous Integration  Sustainable Pace  On Site Customer  Coding Standards

45 XP Roles  The Customer Sets project goals and makes business decisions  The Developer Turn customer stories into working code  The Tracker Keeps track of any metrics used by team  The Coach Guides and mentors team

46 Scrum

47 Scrum Roles  Scrum Team  Scrum Master  Carries water and moves boulders  Product Owner  Responsible for maintaining product backlog

48 Scrum Control Points Meetings:  Sprint Planning  Daily Scrum  Sprint Review (retrospectives and demo)

49 Feature Driven Development (FDD) Deploy Build Feature List Plan By Feature Design by Feature Build By Feature Develop Model Model-driven short-iteration process that consists of five basic activities: - Jeff deLuca, 1997

50 FDD Focus  (Object) Modeling centric  Client centric  Architecture centric  Pragmatic  Functional decomposition  Subject Area  Business Activity  Business Activity Step

51 FDD Roles  Chief Programmers Team lead, mentor, developer  Class owner Developer with responsibility for a class  Feature teams Temporary groups of developers formed around classes

52 Crystal Clear  Frequent Delivery  Reflective Improvement  Osmotic Communication  Personal Safety  Focus  Easy Access to Expert Users  Automated Tests  Configuration Management  Frequent Integration

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 User  Lead Designer  Lead Technical person, mentors less experienced team members  Designer-Programmer  Each person designs and programs

56 DSDM  Active user involvement  Teams empowered to make decisions  Frequent delivery of products  Fitness for business purpose  Iterative and incremental delivery  All changes reversible  Testing throughout lifecycle  Collaboration with all stakeholders

57 Agile Method’s Focus Scrum FDDXP Crystal Project ManagementEngineering Scrum FDD XP Crystal StructuredUnstructured Structure Methodology DSDM

58 Lean Manufacturing  Optimizing production through removal of waste and improving flow  A process management philosophy based on Toyota Production System (TPS)  Focus effort on producing value- added features  Just in time delivery

59 Lean Software Development  Everything not adding value to customer is waste includes:  Unnecessary code and features  Delay in development  Unclear requirements  Bureaucracy  Slow internal communications  By 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 value  Engage customers  Create an environment where individuals can make a difference  Expect uncertainty and manage for it  Context specific strategies, processes, and practices  Group accountability

63 Why Use Agile …

64 Project Challenges

65 Project Statistics Standish 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 Methods  Breaking projects into small chunks  Delivering pieces faster for user feedback

67 Always or Often Used: 20% Never or Rarely Used: 64% Standish Group Study, reported by CEO Jim Johnson, XP2002 Sometimes 16% Rarely 19% Never 45% Often 13% Always 7%

68 Failures Main Reasons For Project Failure :  Lack of end user involvement  Poor requirements  Unrealistic schedules  Inadequate change control  Lack of testing  Inflexible processes

69 Success Factors  User involvement  Management support  Clear vision & objectives  Proper planning  Realistic expectations  Smaller milestones  Competent staff  Ownership

70 Challenges  Deliver the right product  Meet customer’s changing needs  Deliver to rapidly moving market windows  Innovate on both sides of your business model  Get more done by doing less  Lead in the marketplace

71  Deliver Business Value  Increase Productivity  Lead Change  Find Solutions  Innovate Companies Must…

72 Project Management  Remove Obstacles Agile Methodologies Summary

73 Agile Methods Summary  eXtreme Programming, XP  Scrum  Feature Driven Development, FDD  Crystal Methods  Dynamic Systems Development Method, DSDM  Lean Development

74 User Stories Your Questions?

75 Scrum Deep Dive

76 Scrum on a Page Roles Product Owner Scrum Master Team Stakeholders Artifacts Meetings Product Backlog Release Backlog Sprint Backlog Blocks List Information Radiator Sprint Plan Meeting Daily Scrum Sprint Review Meeting Concept inspired by William Wake’s “Scrum on a Page,” Release Plan Meeting

77 Definitions Roles

78 Stakeholders Anyone that can give input to the business objectives of the product.

79 Types of Stakeholders Principals Stakeholders who champion the need for your software and have the authority to acquire and deploy it. End Users Stakeholders who personally interact with your software. Partners Stakeholders who make your product work in real life, such as operations teams and also business partners and system integrators. Insiders Stakeholders 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 “ “

81 Understanding Your Stakeholders Understanding Organizational Context Making Products Consumable Aligning with stakeholder goals Defining Success in Your Stakeholders’ Term Outside-In Software Development 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.

82 I can’t imagine a world without Your product Not only could I imagine a world without it, I long For it Without it, our business would suffer, and I would feel a sense of personal loss It usually does what we want, if painfully at times You know you’re lean when: customers pull compelling value from you effortlessly. “ “

83 Product Owner  Prioritizes backlog in collaboration with …

84 Scrum Master  Removes the barriers between development and the customer so the customer directly drives development  Facilitates creativity and empowerment  Improving the productivity of the development team in any way possible  Improving the engineering practices and tools so each sprint is ready to deploy

85 Scrum Master  Is not the project manager Team manages itself  Doesn’t have authority over the team Team makes decisions  Always asks the question: “How are the Product Owner and Team doing?”  Challenges the organization, key-role in the change However, a dead scrum master is a useless scrum master

86 Team  Add self organizing and ownership bits here. Teams

87 Unleashing Innovation Collaboration Process Exercise

88 Quick Exercise (A) 1.Form pairs 2.Assign one as boss, the other as worker 3.The boss can give the following commands: Go, Stop, Right, Left, Faster, Slower 4.The worker must follow the boss’s commands 5.Goal: 60 steps in two minutes 6.The boss can command the worker but not touch the worker

89 Quick Exercise (B) 1.Everyone is a worker and responsible for figuring out how to proceed during the exercise 2.Goal: 60 steps in two minutes

90 “Self-directed” or “Self organizing” Teams The concepts of leadership, management, and team involvement are prospectively very different  Encouraging a collaborative environment  All roles support one another

91 example: self-organizing teams: 3M

92 Coders/programmers Project Managers ID/Writers Testers Other Roles Product Champion Product Owner Architect Designer The “Whole Team” Concept

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. “ “

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. “ “ Sue McKinney VP MSM Development Pitney Bowes

95 Trust/Ownership Model Command & Control Team Does as Instructed No Ownership Leader / Process is Bottleneck Command & Control Team Does as Instructed No Ownership Leader / Process is Bottleneck Conflict Team Demotivated Mired in Bureaucracy & Wasted Effort Conflict Team Demotivated Mired in Bureaucracy & Wasted Effort Energy & Innovation Team Trusted Team Accountable Leader Freed Energy & Innovation Team Trusted Team Accountable Leader Freed Failure No One Cares Failure No One Cares High How do we get here? Team/Individual Ownership Control Trust Low Leadership & Business Process

96 What Does a Trust Environment Feel Like? Leader’s View  The team won't let me down  The team understands what we need  They will do the right thing  They will tell me if they need help

97 What Does a Trust Environment Feel Like? Individual within the Team  We understand the vision and the need  We are jointly committed to meeting our goals  We stand or fall together  We have Ownership

98 Self-directed teams: Is this lunacy?  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. Two principles supporting the Agile Manifesto :

99 Definitions Roles Summary

100 Roles in a Nut Shell  Stakeholders: gives input as to the product business objectives  Product owner: responsible for the business value of the project  ScrumMaster: ensures that the team is functional and productive  Team: self-organizes to get the work done

101 Artifacts

102 Product Backlog  The current view of the requirements  Consists of Epic User Stories  Prioritised by the Product Owner in collaboration with Stakeholders  Prioritized based on Business Value and Risk

103 Release Backlog  Each Release has a theme  Release Backlog contains the User Stories for that release  Made up of User Stories (broken down Epic User Stories)

104 Sprint Backlog  Each Sprint has a goal  Team agrees on goal and commits to it  User Stories for the Sprint

105 Blocks List  Internal – Actions within the team  External – Actions beyond the team  Updated by the Scrum Master  Scrum Master resolves them with team

106 Information Radiator  Visual representation of progress  Display of:  Work Planned (Product, Release and Sprint)  Work in Progress  Work Done  User Stories to mitigate risk  User Stories to gather information to make future decisions

107 Burndown Chart Part of the Information Radiator

108 Example

109 Artifacts Summary

110  Product backlog: prioritized list of desired project outcomes/features (epic user stories)  Release Backlog: prioritized list of user stories for the release  Sprint backlog: set of work from the product backlog that the team agrees to complete in a sprint  Information Radiator: at-a-glance look at the work progress

111  Leadership Influence Meetings

112 Sprint Planning Meeting  At the beginning of a new Sprint  Chaired by the Scrum Master  Attended by all including Key Stakeholders  Update the Product Backlog with new requirements  Select highest priority items in the backlog based on Business Value  Define the Sprint Goal

113 Daily Scrums  Daily 15 minute status meeting  Same place and time every day  Chaired by Scrum Master  Attended by entire sprint team  Others can attend  Chickens 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 stakeholders  Requests feedback  Team holds retrospective  Updates 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: 1.Executive 2.Internal users 3.Stakeholders 4.Customers

118 How do you know when you’re “done”?

119 Team Defines of “Done” Consider:  No showstoppers  All errors that the team has not agreed to are removed  Code is unit tested, function tested, system tested, performance tested, tested end-to-end  A 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 automation  Appropriate coverage (e.g. 80%)  True test-driven development  Avoiding technical debt  Continuous integration  Really understanding what quality looks like

121 Example 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 tested  It has no Severity 1s or 2s  It has been deployed before a release in a client environment

123 Example They ship  A major release every 3 months  A minor release every month  And minor updates once a week Consider the competitors, teams of developers and they cannot achieve the work flow Patientkeeper does.

124 Retrospective  Keep  Drop  Add Keep? Drop? Add? What surprised you?

125  Leadership Influence Meetings Summary

126 Scrum Meetings Summary  Sprint planning: team and product owner choose work to deliver during a sprint  Daily scrum: team meets each day to share struggles and progress  Sprint reviews: team demonstrates what completed during the sprint  Sprint retrospectives: team discusses ways to improve product and process.

127 Unleashing Innovation Collaboration Process Scrum Exercise

128 Develop a Brochure in a 3 day Sprint Complete Sprint Planning Meeting -10min  Select at least 5 Product Backlog Items  Identify 2 to 3 Tasks per Item Day 1  8 minute day Day 2  2 minute Daily Scrum Meeting  8 minute day Day 3  2 minute Daily Scrum Meeting  8 minute day Demo & Reflection

129 Scrum Deep Dive Summary

130 Scrum on a Page Roles Product Owner Scrum Master Team Stakeholders Artifacts Meetings Product Backlog Release Backlog Sprint Backlog Blocks List Information Radiator Sprint Plan Meeting Daily Scrum Sprint Review Meeting Concept inspired by William Wake’s “Scrum on a Page,” Release Plan Meeting

131 Scrum Best Practices  Test Driven Development  Pair testers and developers  Continuous Integration

132 References  what_is_scrum  scrum_student_resources  The Elegant Solution, Matthew May  Outside-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

134 Scrum Deep Dive - Questions Scrum Deep Dive Questions?

135 Leading Agile  Collaboration Model  Collaboration Process User Stories

136 User Stories Overview  Basics  Creating  Refine  Flow

137 Leading Agile  Collaboration Model  Collaboration Process User Story Basics

138 What is a User Story? A concise, written description of a piece of functionality that will be valuable to a stakeholder. As a, I can so that

139 User Story Roles As a, I want to so that I can  Avoid “the user” as different stakeholders have different needs  M. Cohn recommends using roles so that you do not “miss” stories  Teams can develop a set of user roles to help define relevant stories

140 User Story Goals As a, I want to so that I can  Goal is “what the role can do”  Valuable to a stakeholder  Doesn't say “how”, but “what”

141 User Story Business Value As a, I want to so that I can  Justifies the value of the story  Clarifies why a feature is useful  Can influence how a feature should function  Helps prioritize the story in the backlog  Can lead to other useful features that support the user’s goals

142 Example As an I can So that

143 Example NASA 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 Exercise  At your table, build three user stories

145 Why use User Stories?  Right size for planning, works for iterative development  Defer detail until you have the best understanding you are going to have about what you really need  Focus on user goals rather than feature attributes

146 Why use User Stories?  Emphasize verbal rather than written communication  Potentially fixes issues with “vague requirements”  Comprehensible by both stakeholders and the development team  Stories support evolutionary development

147 Where User Stories Help Value to Stakeholders  Stories target functionality valuable to stakeholders  Story demos each iteration engage stakeholders

148 Where User Stories Help Simplified Features  Stories enable light-weight requirements gathering, progressive discovery  Stories focus on feature essentials

149 Where User Stories Help Release Predictability  Stories by definition fit in time-boxed iteration  Stories that fail in an iteration provide early warning system  Cadence of story completion over multiple iterations will demonstrate release predictability

150 Leading Agile  Collaboration Model  Collaboration Process Creating User Stories

151 Release Themes  Release themes are based on business objectives  A well known release theme is critical to team success  Themes 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 Stories Epic User Stories capture stakeholder goals for release themes.  Epic User Stories fit into releases  Will not likely fit in an iteration  Team has an idea of how large the effort is  Product backlog contains Epic User Stories  Create Epic User Stories with Stakeholders  This is the product backlog.

154 Creating User Stories 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. Don’t focus only on the end-user role. Consider other stakeholder types as well.

155 Creating Epic User Stories Insiders : As a database administrator I can back up a database So 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 code So 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?

159 Unleashing Innovation Collaboration Process Exercise

160  At your table, pick a product  Create Release Themes  Create 2-3 Epic User Stories for the first/next 3 releases

161 User Story Team Create a User Story Team, including (but not limited to):  Product Owner  Stakeholders  Scrum Master  Cross-disciplinary Representatives from the scrum team Technical knowledge required

162 User Story Team Stakeholders on User Story Team  Represent each important stakeholder type: Principles End Users Partners Insiders  If real stakeholders are not available, assign stakeholder champions (team members)  Champions get to know the stakeholder, understand their requirements

163 User Story Team Refer 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 input  Agree on success factors for release  Use team to develop the first draft of user stories  Use appropriate team members to further re/define stories right before every iteration

165 Leading Agile  Collaboration Model  Collaboration Process Refining User Stories

166 Project Management How Do We Deliver? Breaking stories into smaller stories

167 Using User Stories  Break Epic User Stories into smaller User Stories  Break Epics for the next one (or two) releases  User Stories by definition fit into an iteration  User Stories from the Release Backlog  Avoid user stories that are too small: When documenting the story takes longer than implementing it Bugs, user interface tweaks, etc.

168 User Stories Successful iterations have multiple small stories:  Smaller stories can be implemented & tested progressively throughout the iteration  Reduces the time between code and test

169 Who Sizes the Stories? Cross-disciplined scrum team that will deliver the story  Stories are sized in "story points" – relative to one another Based on the team’s skills Based on the technology they will use  Use “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 conversations  If technology is unknown, use architectural spikes Short (time-bounded) iteration to learn “just enough” to proceed

171 Break Stories into Smaller Stories

172 User Stories Recommendation: Do not maintain a hierarchy of stories under an epic Easier to manage a flat list of user stories Hierarchical stories overcomplicate the backlog Hard to remove smaller stories

173 Splitting on Operational Boundaries First:  Basic User Interface  50% of search fields  Parts of query builder that used those fields  Message “search found 297 matches” Second:  Data display grid Third:  Remaining search fields  Remainder of query builder Search Screen Fields Complex Data Display Grid Data- base Query Builder Query Builder

174 Splitting into separate CRUD operations  As a technical marketing rep, I can add (create) an orderable part to the online catalog  As a technical marketing rep, I can view (read) the list of orderable parts in the online catalog  As a technical marketing rep, I can edit (update) an orderable part in the online catalog  As a technical marketing rep, I can remove (delete) orderable parts from the online catalog CREATEREADUPDATEDELETE

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:  Security  Logging  Error handling  Etc.

176 Attributes of a Good User Story Attribute Explanation Independent Does not depend on other stories Negotiable Not all details necessary Valuable Has tangible value to stakeholders of the software Estimate-able You can estimate stories via story points Small Fits in an iteration by definition Testable Required to demonstrate that story is “done” INVEST ( From Mike Cohn)

177 Exercise  Break 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 Agile  Collaboration Model  Collaboration Process User Stories Flow

179 Flow: The Big Picture Select High-priority Stories Create/size User Stories Trawl for Requirements Time Boxed Iteration Demo Working Code to Stakeholders Reflect & Take Action Epics Stories Iteration Backlog Get Feedback Release Planning Stakeholder Goals Refine Stories, Plan Work Scrum Code, Doc & Test Discuss Story Progress Epics Stories Release Backlog

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 feature  Feature design & functionality will adapt to what becomes possible in the technology as you use it & learn about it  Release priorities, market forces, and stakeholder needs change throughout the life of the product  Team members learn from stakeholders as they go

181 Evolutionary Design: How it can work Map content released functionality iteratively 1: Input an address and see the location on a street map 2: Input two addresses and get directions between them 3: Change the route by dragging the route to other streets If 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 it Lessons? Evolutionary feature design worked Get “enough” functionality out sooner Discover what feature to add next based on feedback Jun/10181 User Stories Summary

182 User Stories Overview  Basics  Creating  Refine  Flow

183 Terms  Epic User Story  User Stories  Release Themes  Champions  Architecture Spikes

184 References  Agile Project Planning: Writing Good User Stories: 1/writing-good-user-stories.html User Stories Applied, Mike Cohn

185 User Stories Your Questions?

186 Reflection

187 Key Characteristics of Successful Agile Projects Short, Stable, Time-Boxed Iterations Stakeholder Feedback Self-Directed Teams Sustainable Pace

188 Project Framework

189 Project Framework - Iteration Plan Inception Elaboration ConstructionTransitionProduct- ion consumability tasks integration with other components / products globalization and translation focus Architectural “Spikes” Prototyping

190 Framework – Overlapping Releases Inception Elaboration ConstructionTransitionProduct- ion Inception Elaboration Construction

191 Framework - Overlapping Releases Warning: Beware of PowerPoint Architects Inception Elaboration ConstructionTransitionProduct- ion Inception Elaboration


Download ppt "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 n."

Similar presentations


Ads by Google