Scrum Essen+als Presented by Riad Bacchus Riad_bacchus@hotmail.com LinkedIn/Riad Bacchus
Overview • Scrum Overview How does it all work? • Scrum Planning How do we plan the project? • Scrum Roles Who’s responsible? • Scrum Ar+facts What documents are needed? • Scrum Mee+ngs What mee9ngs drive Scrum?
Scrum Overview • Developed in 1993 • Scrum is one of several Agile Methodologies • Scrum is part of the Agile Alliance • Has been used on thousands of projects • Used internally by various MicrosoN teams • Can manage projects of 2 -‐ 3000 team members
Scrum Cycles Program 2-n months Project 2-n months Release 2-6 months Sprint 30 days Daily Scrum daily
Project Success Decline Over Time This graph indicates the sharp decline in project success the longer a project runs without shipping a release. 1-‐6 months seems to be the sweet spot.
Working vs. Released SoNware Sprint 1 Sprint 2 Sprint 3 Sprint 4 (Normal) (Normal) (Normal) (Release) Sprint 5 Sprint 6 Sprint 7 Sprint 8 (Normal) (Release) (Normal) (Release) • During normal sprints, working soNware is “DONE” but might not be “released”. • During release sprints, working soNware is deployed.
Scrum Planning • A Scrum project is planned up front & as we go. • Up front? – Set expecta+ons based on “ini+al” scope. – Develop a priori+zed product backlog. – Assign “order of magnitude” es+mates. (+75%/-‐25%) – Deﬁne desired +ming for produc+on releases. – Es+mate resources needed. – Es+mate sprint count • As we go! – At the start of each sprint, plan 30 days of scope. – Reﬁne es+mates, priori+es and product backlog.
Scrum Roles ScrumMaster Product Owner • Establish vision • Teach / Coach Scrum • Set Sprint Goals • Manage Process • Set Priori+es • Protect Team • Owns the Product Backlog • Enforce Rules • Remove Blocks • Facilitate Mee+ngs Stakeholder Team • Observe • Organize work • Advise • Develop product • Communicate issues & progress
Scrum Ar+facts Sprint Backlog • Product Backlog List of requirements • Decomposed task list • Owned by Product Owner • Driven by a por+on of Product • Anybody can add to it Backlog • Owned by Team • Priori+zed by business value • Only Team modiﬁes it • Can change without aﬀec+ng the ac+ve Sprint Sprint Goal Blocks List • One sentence summary • List of blocks & pending • Deﬁned by Product Owner decisions • Accepted by Team • Owned by ScrumMaster • Blocks stay on list un+l resolved Increment • Version of the product • Potentially shippable • Working functionality • Tested & documented according to project definition of “DONE”
Sample Product Backlog • The scope list • A, B, C feature dis+nc+on • Priori+zed by • Rough es+mates help size the business value sprints
Sample Sprint Backlog • Granular tasks (2-‐40 hours each) • Assigned to team members • Es+mates adjusted daily by team • Managed by the team
Sample Burndown Chart • Provides candid transparency • Printed daily • Posted publicly • May be bumpy
Scrum Mee+ngs Sprint Planning -‐ A Daily Scrum • Time-‐boxed: < 4 hours • Time-‐boxed: < 15 minutes • Run by ScrumMaster • Run by ScrumMaster • Declare Sprint Goal • Aoended by all • Top of Product Backlog presented • Stakeholders do not speak by P.O. • Same +me/place daily • Team asks ques+ons & selects • Answer 3 ques+ons: topmost features 1) What I did yesterday Sprint Planning -‐ B 2) What I’ll do today • Time-‐boxed: < 4 hours 3) What’s in my way • Run by ScrumMaster • Sprint Backlog updated • Team decomposes features into a • ScrumMaster updates blocks Sprint Backlog • Team adjusts +/-‐ features by task es+mates against sprint capacity Sprint Retrospec+ve Sprint Review • Time-‐boxed: 1-‐2 hours • Time-‐boxed: < 4 hours • Run by ScrumMaster • Run by ScrumMaster • Aoended by Team and P.O. • Aoended by all • Discuss process improvements, • Team demonstrates increment wins and losses • All discuss • Adjust process
Review • Scrum Overview How does it all work? • Scrum Planning How do we plan the project? • Scrum Roles Who’s responsible? • Scrum Ar+facts What documents are needed? • Scrum Mee+ngs What mee9ngs drive Scrum?
Roles Q&A • What if the client doesn’t know how to be a Product Owner? – It is common for a client to be willing, but inexperienced as a P.O. In this case, the ScrumMaster must lead the client through the tasks of building a Product backlog, priori+zing and elabora+ng features. Remember, teaching is part of the duty of a ScrumMaster. Leading the P.O. through the mo+ons ini+ally is a great way to teach. – The ScrumMaster needs to set expecta+ons with the client as to their role in the success of the project. – Regardless of Agile or Tradi+onal project methods, a project that doesn’t have strong support and par+cipa+on from the key stakeholders is very likely to fail. – If the client refuses to accept some or all of the du+es of Scrum’s version of a P.O., the ScrumMaster may proxy for the Product Owner. However, this adds risk, and fails to truly empower the client. • What if the client or a team member keeps breaking the rules? – The ScrumMaster’s primary duty is to protect the team’s +me and focus to achieve stated project goals. The ScrumMaster must seriously address any disregard for the process.
Product Backlog Q&A • What does Neudesic use to manage a Product Backlog – TFS – (OR) A spreadsheet Product Backlog (posted to SharePoint) • Can Neudesic create the Product Backlog for the client? – Preferably not. But in many cases, we’ll need to help teach the client how to maintain a backlog. – In the absence of a strong client leader who can be assigned the clear “Product Owner” role, we have no choice but to serve as the Product Owner. • What should the Product Backlog contain? – Item Name – Priority (according to business value) – User Story (1-‐2 paragraphs descrip9on) – Status (New, Approved, In Progress, Completed, Cancelled) – Sprint Number • When can the Product Backlog change? – Any +me (except for sprint planning day). – Reﬁne es+mates, priori+es and product backlog.
Product Backlog Q&A cont’d • Does the Product Backlog ever contain items other than product features? – Yes. ONen, major tasks (40 hours+) are priori+zed in the backlog even if they do not strictly represent features. System Stories are used to capture security, performance and infrastructure requirements. – Examples: Integrate SharePoint with MIIS, User Training Guide. • Don’t changes to the backlog aﬀect project scope? – Yes. In some cases the changes represent a small impact to overall project outcome. In others, the changes will require a revisit of the program/project/ release planning constraints and es+mates. – If the Product Owner makes signiﬁcant changes (addi+ons) to the Product Backlog, this should force a conversa+on between the ScrumMaster and the Product Owner resesng expecta+ons. – However, this should be done in the spirit of “harnessing change” vs. “preven+ng change”.
Sprint Backlog Q&A • When is the Sprint Backlog created? – During the sprint planning mee+ng (day 1 of each sprint). • How is the Sprint Backlog diﬀerent from the Product Backlog? – It contains “tasks”, whereas the Product Backlog primarily contains priori+zed features and major eﬀorts. – The tasks it contains are usually “decomposed” down to 8-‐40 hour eﬀorts. – The Team creates and maintains the Sprint Backlog. Only they are allowed to add or remove tasks. • How does the team know enough on day 1 of the Sprint to accurately es+mate tasks in the Sprint Backlog? – They might not. But, their job in the sprint planning mee+ng is to ﬁnd out (and write down) enough clarifying details to be accurate enough in their es+ma+ons for the purposes of a 30-‐day planning window. – Depending on how well deﬁned the sprint features are, the team may choose not to “ﬁll up the sprint” en+rely, allowing some +me do deal with the unknown.“
Sprint Backlog Q&A cont’d • Can the Team add items to the Sprint Backlog during the Sprint? – Yes, the team is free to add tasks to the Sprint Backlog throughout the Sprint, so long as they are directly associated with mee+ng the stated sprint goal and the speciﬁc features that were selected from the Product Backlog. – No, the team is not free to silently select addi+onal features from the product backlog during the Sprint. They are encouraged to ask the Product Owner for addi+onal features if they feel there is room for more. • Who assigns team members to tasks? – The Team works out its own assignments during Sprint Planning. – The Team can at any +me adjust assignments to op+mize outcomes. • How detailed must Sprint Backlog items be? – They should be broken down into tasks discrete enough for the team to see how they’ll accomplish the selected Sprint scope. – A good rule of thumb is: tasks of 8-‐24 hour dura+on. – Key mee+ngs should be included (e.g. design workshops 2+ hours, integra+on work sessions 2+ hours) as they tend to add up when all team members are present.
Further Reading • Agile SoNware Development with Scrum 2002, Pren+ce Hall, Ken Schwaber, Mike Beedle. (#1 read for anyone serious about Scrum) • Agile Project Management with Scrum 2004, MicrosoN Press, Ken Schwaber. (A bit more ﬂuﬀy, but has a lot of case studies) • Agile & Itera+ve Development 2004, Pearson Educa+on, Craig Larman. (#1 read to introduce and compare Agile methods) • Agile SoNware Development 2002, Pearson Educa+on, Alistair Cockburn . (Provides the science and the “why’s” of Agile methods)