Introduction to Agile Project Management and Scrum

Eric Krock Co-‐Founder, Voximate @voximate http://www.voximate.com/blog/

Why Waterfall Usually Sucks Problem Consequences Serialized process: MRD Longer time to market; developers isolated from – PRD – Design customer needs Document – Dev -‐ QA Planning far in advance Plans no longer match reality by the time they’re implemented Lack of visibility into Teams don’t realize they’re behind schedule until too rate of progress late Features slashed very late to compensate, wasting eﬀort and leading to Swiss-‐cheese products (e.g. MS Kin) Long time to project Customers get access to new features infrequently completion and after long delay Customers can only provide feedback “too late” Process doesn’t allow for rapid incremental learning Projects fall behind Projects miss market window or are killed before schedule launch

Why PRDs Usually Suck   Long   Monolithic   Unreadable and unread   Often disconnected from actual customer needs   Lack of clarity about what features are for which customers

User Stories   Express a customer need as a story about a real or composite user in the language of the customer   As a [USER ROLE], I [must / want / wish to] [need] so that [user goal]   Short: can ﬁt on an index card   Example: “As a project manager, I must track each task’s delivery deadline so that I can make sure tasks are completed on team.”   Small amount of work: can ﬁt within a day or a sprint   Should include notes for needed acceptance test Source: Mike Cohn, User Stories Applied

Es7mate Eﬀort for Story in Points   “Story point” = abstract, RELATIVE estimate of amount of work to complete a story   Optional: Using Fibbonacci sequence forces clear distinctions in diﬃculty: 1, 2, 3, 5, 8, 13, 21 …   Teams must agree on estimate for each story   Tracking velocity (points completed per sprint) will measure team’s true capacity   Issues: measure with points, or not? Source: Mike Cohn, Agile Estimating and Planning

Release Plan   Combines multiple sprints to achieve larger goal   Capacity = number of sprints * expected velocity   Choose list of stories with total story points no greater than capacity Source: Mike Cohn, Agile Estimating and Planning, Chapter 13, “Release Planning”

Divide Workload Into Short Sprints   Sprint = short, ﬁxed-‐length interval for development   Usually 1-‐2 weeks   Key: Must return product to potentially shippable state at end of sprint!   Reduces accumulation of technical debt   Keeps assessment of project progress realistic

Key Concepts in Scrum   Product Owner: voice of the customer, facilitates writing of user stories   ScrumMaster: manages the sprints   Team: do the work!   Collective ownership   Daily standup: did yesterday, doing today, stuck on … Source: Mike Cohn, User Stories Applied, Chapter 15

Development Concepts   Test driven design*   Depth-‐ﬁrst development * Source: Kent Beck, XP Explained

Sprint Commit Mee7ng   At start of each sprint, team meets and commits which stories they will do for the sprint.   Make decision based on tasks for each story and estimated hours for all tasks, not based on points.   Key: After sprint commit meeting, no new stories can be added to that sprint.   For true emergencies, must remove equal amount of work if add something in after sprint commit. Source: Mike Cohn, User Stories Applied

User Stories  Conversa7ons   User story is basis for a conversation with developer   Conversation (not the user story) is basis for actual development   Goals:   Get engineering talking to product owner, customers, etc.   Get deeper mutual understanding of the story by talking about it   Increase odds that features developed will actually satisfy customer’s needs Source: Mike Cohn, User Stories Applied

Sprint Burndown Chart Sprint Hours of Work Remaining 70 60 50 40 30 20 10 0 3/27/11 3/28/11 3/29/11 3/30/11 3/31/11 4/1/11

Sprint Review Mee7ng   At end of sprint, review what work actually got done.   Velocity = total points for all user stories completed during sprint.   No partial credit for partially-‐complete stories!   Estimated time to project completion = total story points for all stories in project / moving average of velocity   Moving average = average velocity of last three sprints   Team’s accuracy estimating doable work per sprint should improve over time Source: Mike Cohn, Agile Estimating and Planning

Project Burndown Chart 400 350 300 250 Points Closed 200 Points Added 150 Points Remaining 100 50 0 1/7/11 1/14/11 1/21/11 1/28/11 2/4/11 2/11/11 2/18/11 2/25/11 3/4/11

Backlog: Per-‐Project, or Per-‐Release?   Backlog is list of all stories not yet assigned to a sprint   Simple project, single release: single backlog   Beneﬁt: simplicity   Long-‐lived project with multiple releases: may have one backlog per release   Beneﬁt: do initial division of work by release, then divide each release’s work into sprints during development; product owner needn’t review ALL stories at every sprint

Agile Best Prac7ces Best Practice Benefit Don’t write stories too far in advance of Avoid wasted effort on stories that are development.* not implemented. Use best, most-‐current information when writing story. Don’t event tentatively schedule stories Avoid wasted effort of moving stories more than 2-‐3 sprints in advance. when priorities change. Have customers write and prioritize Let customers express their needs. user stories.* Avoid “telephone game” problem. Force customers to make tradeoffs. * Source: Mike Cohn, User Stories Applied

Key Agile Values   Communication   Transparency   Honesty   Incremental eﬀort   Incremental learning feedback For fuller list of Agile / XP values, see Kent Beck, XP Explained, Chapters 3-5

Agile Versus Tradi7onal Waterfall Metric Waterfall Agile Planning scale Long-‐term Short-‐term Distance between Long Short customer and developer Time between Long Short speciﬁcation and implementation Time to discover Long Short problems Project schedule risk High Low Ability to respond Low High quickly to change

Addi7onal Reading Book Author Notes User Stories Applied Mike Cohn Intro to Agile and use of user stories for expressing requirements. Agile Estimating and Mike Cohn Deep dive on Agile metrics, Planning estimating, and project planning. Succeeding with Agile Mike Cohn Tips on rolling out Agile in a larger organization. Extreme Programming Kent Beck Introduction to XP Explained

Addi7onal Resources   http://www.mountaingoatsoftware.com/ Mike Cohn’s site with blog, presentations, more   http://agilemanifesto.org/   http://www.agilealliance.org/   http://www.scrumalliance.org/

Introduction to Agile Project Management and Scrum

by Voximate on Apr 07, 2011

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 21

Statistics

Introduction to Agile Project Management and Scrum Presentation Transcript