Embed Size (px)
DESCRIPTION
Citation preview
• 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?
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 Overview
Scrum Cycles
Program
Project
Release
Sprint
Daily Scrum daily
30 days
2-6 months
2-n months
2-n months
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.
• During normal sprints, working soNware is “DONE” but might not be “released”.
• During release sprints, working soNware is deployed.
Working vs. Released SoNware
Sprint 1 (Normal)
Sprint 2 (Normal)
Sprint 3 (Normal)
Sprint 4 (Release)
Sprint 5 (Normal)
Sprint 7 (Normal)
Sprint 8 (Release)
Sprint 6 (Release)
• 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%) – Define 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. – Refine es+mates, priori+es and product backlog.
Scrum Planning
Product Owner
Scrum Roles
• Establish vision • Set Sprint Goals • Set Priori+es • Owns the Product Backlog
Stakeholder • Observe • Advise
Team • Organize work • Develop product • Communicate issues & progress
ScrumMaster • Teach / Coach Scrum • Manage Process • Protect Team • Enforce Rules • Remove Blocks • Facilitate Mee+ngs
Product Backlog
Scrum Ar+facts • List of requirements • Owned by Product Owner • Anybody can add to it • Priori+zed by business value • Can change without affec+ng
the ac+ve Sprint
Sprint Goal • One sentence summary • Defined by Product Owner • Accepted by Team
Blocks List • List of blocks & pending
decisions • Owned by ScrumMaster • Blocks stay on list un+l resolved
Sprint Backlog • Decomposed task list • Driven by a por+on of Product
Backlog • Owned by Team • Only Team modifies it
Increment • Version of the product • Potentially shippable • Working functionality • Tested & documented
according to project definition of “DONE”
• The scope list
• Priori+zed by business value
Sample Product Backlog • A, B, C feature dis+nc+on
• Rough es+mates help size the sprints
• Granular tasks (2-‐40 hours each)
• Assigned to team members
• Es+mates adjusted daily by team
• Managed by the team
Sample Sprint Backlog
• Provides candid transparency
• Printed daily
• Posted publicly • May be bumpy
Sample Burndown Chart
• Time-‐boxed: < 4 hours • Run by ScrumMaster • Aoended by all • Team demonstrates increment • All discuss
• Time-‐boxed: < 15 minutes • Run by ScrumMaster • Aoended by all • Stakeholders do not speak • Same +me/place daily • Answer 3 ques+ons:
1) What I did yesterday 2) What I’ll do today 3) What’s in my way
• Sprint Backlog updated • ScrumMaster updates blocks
• Time-‐boxed: < 4 hours • Run by ScrumMaster • Declare Sprint Goal • Top of Product Backlog presented
by P.O. • Team asks ques+ons & selects
topmost features
Scrum Mee+ngs
Sprint Retrospec+ve • Time-‐boxed: 1-‐2 hours • Run by ScrumMaster • Aoended by Team and P.O. • Discuss process improvements,
wins and losses • Adjust process
Sprint Review
Daily Scrum Sprint Planning -‐ A
• Time-‐boxed: < 4 hours • Run by ScrumMaster • Team decomposes features into a
Sprint Backlog • Team adjusts +/-‐ features by task
es+mates against sprint capacity
Sprint Planning -‐ B
Scrum on a Page
• 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?
Review
• 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.
Roles 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). – Refine es+mates, priori+es and product backlog.
Product Backlog Q&A
• 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 affect 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 significant 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”.
Product Backlog Q&A cont’d
• When is the Sprint Backlog created? – During the sprint planning mee+ng (day 1 of each sprint).
• How is the Sprint Backlog different from the Product Backlog? – It contains “tasks”, whereas the Product Backlog primarily contains priori+zed
features and major efforts. – The tasks it contains are usually “decomposed” down to 8-‐40 hour efforts. – 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 find 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 defined the sprint features are, the team may choose not to “fill up the sprint” en+rely, allowing some +me do deal with the unknown.“
Sprint Backlog Q&A
• 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 specific 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.
Sprint Backlog Q&A cont’d
• 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 fluffy, 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)
Further Reading
![Scrum XP - agilesociety.co.kr1].pdf · 극대화시키는애자일방법론(Agile Software Development with Scrum)』혹은『스크 럼을통한애자일프로젝트관리 (Agile](https://img.pdfslide.tips/doc/110x75/5e06d03682523a2a533fd839/scrum-xp-1pdf-eeoeoeeeeeagile-software-development.jpg)
