Introduction to Agile Project Management and Scrum

download Introduction to Agile Project Management and Scrum

of 20

  • date post

  • Category


  • view

  • download


Embed Size (px)


Brief introduction to Agile Project Management and Scrum covering user stories, story points, use of Fibonacci sequence values for story points, release planning, sprints, capacity, velocity, sprint commit meetings, sprint review meetings, and burndown charts. Explains the importance of returning the product to a potentially shippable state at the end of each sprint to reduce the accumulation of technical debt and keep the assessment of project progress realistic. Summarizes the roles in Scrum of the Product Owner (who writes or facilitates the writing by customers of user stories), the ScrumMaster (who manages the Scrum), and the Team (who do the work). Discusses values and best practices in Agile/Extreme Programming ("XP") values. Explains daily standup meeting in which people share what they did yesterday, what they're doing today, and any blocking issues they're encountering. Summarizes common problems with waterfall project management including a serialized process, longer time to market, isolation of developers from customer needs, plans falling out of synch with reality, lack of visibility into rate of progress, features being slashed late in the development cycle to bring in release dates, long time to project completion, late feedback from customers, projects falling behind schedule, and projects missing their market window or being killed before launch. Summaries problems with monolithic product requirements documents including length, lack of readability, disconnection from customer needs, and lack of clarity about which features are for which customers.

Transcript of Introduction to Agile Project Management and Scrum

  • 1. Eric Krock Co-Founder, Voximate @voximate

2. 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 theyre implemented Lack of visibility into Teams dont realize theyre behind schedule until too rate of progress late Features slashed very late to compensate, wasting eort 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 doesnt allow for rapid incremental learning Projects fall behind Projects miss market window or are killed before schedule launch 3. 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 4. 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 tasks 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 5. Es7mate Eort 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 diculty: 1, 2, 3, 5, 8, 13, 21 Teams must agree on estimate for each story Tracking velocity (points completed per sprint) will measure teams true capacity Issues: measure with points, or not? Source: Mike Cohn, Agile Estimating and Planning 6. 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 7. 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 8. 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 9. Development Concepts Test driven design* Depth-rst development * Source: Kent Beck, XP Explained 10. 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 11. 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 customers needs Source: Mike Cohn, User Stories Applied 12. 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 13. 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 Teams accuracy estimating doable work per sprint should improve over time Source: Mike Cohn, Agile Estimating and Planning 14. 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 15. Backlog: Per-Project, or Per-Release? Backlog is list of all stories not yet assigned to a sprint Simple project, single release: single backlog Benet: simplicity Long-lived project with multiple releases: may have one backlog per release Benet: do initial division of work by release, then divide each releases work into sprints during development; product owner neednt review ALL stories at every sprint 16. Agile Best Prac7ces Best Practice Benet Dont write stories too far in advance of Avoid wasted eort on stories that are development.* not implemented. Use best, most-current information when writing story. Dont event tentatively schedule stories Avoid wasted eort 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 tradeos. * Source: Mike Cohn, User Stories Applied 17. Key Agile Values Communication Transparency Honesty Incremental eort Incremental learning feedback For fuller list of Agile / XP values, see Kent Beck, XP Explained, Chapters 3-5 18. Agile Versus Tradi7onal Waterfall Metric Waterfall Agile Planning scale Long-term Short-term Distance between Long Short customer and developer Time between Long Short specication and implementation Time to discover Long Short problems Project schedule risk High Low Ability to respond Low High quickly to change 19. 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 20. Addi7onal Resources Mike Cohns site with blog, presentations, more