Download as PDF, PPTX
Uploaded bybeITconference
Scrum Crash Course - Anatoli Iliev and Lyubomir Cholakov, Infragistics
This document provides an agenda and overview for a Scrum training session. The training will cover topics such as the principles and ceremonies of Scrum, including roles, product backlog, sprints, daily standups, sprint reviews, and retrospectives. It will use presentations and a Lego game to help illustrate key Scrum concepts. The goal is to introduce participants to Scrum and provide them a basic level of knowledge about how to implement Scrum practices in their work.
More Related Content
Similar to Scrum Crash Course - Anatoli Iliev and Lyubomir Cholakov, Infragistics
Scrum Crash Course - Anatoli Iliev and Lyubomir Cholakov, Infragistics
- 1.
- 2. Introductions SCRUM what?!? Raise yourhand at the one that applies. • Your level of experience with Scrum? – Novice – Somewhere in Between – Expert • How do you feel about Scrum? – Skeptic / Doesn’t work – In between – Strong Advocate
- 3. Agenda • 16:45 –18:15 – Training • 18:15 -19:45 – Lego game
- 4. Why scrum andagile…
- 5.
- 6.
- 7.
- 8. The Three Pillarsof Scrum
- 9.
- 10.
- 11.
- 12.
- 13.
- 14. Roles of theTeam
- 15.
- 16. Modeling Summary Iteratively andcontinuously, understand users, refine requests into lightweight requirements that meet there's needs and our product / project then create just enough specs so that we can build Context (product vision, business case) Stakeholders Product ownerRequirements Scrum Team
- 17. Requirement – Morethan Just a Story • Matured request that identifies attributes, capabilities and qualities that a system must possess for it to provide value • A key component a user story or other concise expressions of a request • Provides perspective to envision enough of the implementation possibilities to assign a story point estimate and re-prioritize Requirement, more than a just a user story, enough to plan
- 18. User Stories User storytemplate is simplistic, it helps us remember a need while providing content As a driver I want to find a conveniently located branch So that I can minimize travel time User, User role, Persona (WHO?) Specifies the primary beneficiary, others ca also use. Desired Function (WHAT?) End Result (WHY?)What is not specified and why?
- 19. User Stories -Samples First attempt with context As a user I want to modify system users We want administrators to be able to assign access privileges to users based on their role to secure access to functions and data based on need to know / do. Improved, Good Enough?
- 20. Specification, Ready toBuild To be confident we can complete our sprint work just enough specs, just in time, to allow us predictably build • Often we need nothing more than the requirement and a quick conversation • We may also benefit essential use cases, prototypes, API signatures ,sample XML, etc. to clarify external or internal design Spec Requirements Additional Conversations Examples / Designs Context (Project Vision, Design Standards, etc.)
- 21. Ceremonies and Artifactsof Scrum
- 22.
- 23. Discovery Sessions ata Glance Description Series of facilitated sessions to orient team to the project’s business value, the process, and one another, while preparing to excellence. Not part of Scrum Framework but often helpful. Duration One day – multiple weeks Attendees Team, Product Owner, Key Stakeholders, Scrum Master, Subject matter experts Outputs: • Product Vision • Project approach • Team norms • Team rooms • Business process definition • Initial backlog • Dev. + test environments • Dependency list • Risk list • Etc.
- 24. Discovery, aka Iteration0 • Agile Process Training • Product Discovery • Product Roadmap • Initial system design • Architecture spike • Collaborative modeling workshop • Feature and epic prioritization and estimation • Team Discovery • Team norms and core hours • Sprint duration • “Ready” and “Done” definition • Team structure (core / extended) • Stakeholder / Project interactions • Process Discovery • Process value stream map • Supplier customer diagram • Key metrics (CTQs) • Project Discovery • Sponsor vision and business context • Preliminary release planning • Preliminary sprint planning • Major dependencies and risks • Environment • Version control and build environments • Team room • Team board Sample Discovery Session(s) might include:
- 25.
- 26. Release Planning ata Glance Description Optional, but recommended project planning session, to review initial Product Backlog and set production Release dates. Duration Depends on team maturity, ideally under one day. Attendees Team, Product Owner, Scrum Master, Subject matter experts Outputs: • Referred product backlog with initial / updated estimates and priorities • Updated release plan • Updated roadmap
- 27.
- 28.
- 29. Agile Estimating andForecasting
- 30. Two Levels ofEstimating Release planning estimates are done with RELATIVE STORY POINTS focusing on Size, Complexity and Risk 3 is 50% bigger than 2 A modified Fibonacci sequence 1, 2, 3, 5, 8, 13, 20, 20 & 100 T-shirt sizes – XS, S, M, L, XL Over time, story points automatically encompass external interruptions, technical surprises, developer skill level, unplanned absences, domain knowledge and other factors Doesn’t decay over time Sprint Level estimating sometimes includes a look at story points, and sometimes task level estimating Task hours Task sub points
- 31. Estimate with StoryPoints - benefits Relative measure of Size, Complexity and Risk 3 is 50% bigger than 2 A modified Fibonacci sequence 1, 2, 3, 5, 8, 13, 20, 20 & 100 T-shirt sizes – XS, S, M, L, XL Over time, story points automatically encompass external interruptions, technical surprises, developer skill level, unplanned absences, domain knowledge and other factors Doesn’t decay over time Based on “Wideband Delphi” convergent estimation techniques 1. Each team member (estimator) has a deck of cards 2. Moderator (PO) reads a story and it is briefly discussed 3. Estimators select a card & places it face down on the table 1. Cards are turned over all at once 2. Outliers are discussed 3. Re-estimate is run until estimates converge (or don’t!) Estimation Try 1 Try 2 Try 3 Konstantin 3 5 5 Ivo 8 5 5 George 2 3 5 Monika 8 5 5
- 32. Planning Poker inAction Planning Poker Approach 0. Define the meaning of 1 1. Each estimator has a card deck (whole team) 2. A Moderator (PO) reads a story and it is briefly discussed 3. Each estimator selects a card and places it face down on the table 4. Cards are turned over all at once 5. Differences (especially outliers) are discussed 6. Re-estimate until estimates converge (or don’t)
- 33. Velocity Basics Sumof planned, completed functionality in a Sprint, for example: Team estimated 36 points worth of stories during Sprint Planning One story, worth 8 points was not completed, the others were Their current velocity is _____ points? Work actually completed in prior sprints, all things being equal, is a good predictor of work that can be completed in the future Effective is a release planning metric Not effective as a productivity metric or to compare across teams Measure work completed, forecast future throughput
- 34. Product Backlog ata Glance Discovery Session Release Planning Product Backlog Production Ready Features Burndown Sprint Backlog Sprint Planning Daily Scrum Work Sprint Review Sprint Retro Start Sprint Daly Scrum End Sprint Description List of desired functionality for a project prioritized by business value by the PO Managed by • Contains requirements as “User Stories” • Top priority stories are better defined • DEEP • Detailed Appropriately • Estimated • Emergent • Prioritized Key Characteristics • PO / Scrum Master Contains: • Prioritized Product Backlog Items or User Stories • Rough Estimates • Forecasted iteration boundaries • Release Dates
- 35. Sample Product Backlog IDBacklog Item Acceptance Criteria Points Spr int 1 114 As a Guest I want to Make a Reservation So that I can get a room of my choice Confirmation e-mail is sent Must be made > 24 hours in advance 2 S1 2 127 As a Guest I want to Cancel a Reservation So that I can receive a full refund Confirmation e-mail is sent Must be cancelled > 24 hours in advance 2 S1 3 109 As a Guest I want to change reservation dates ….. 4 S1 4 112 As a hotel employee I want to see future reservations …… 8 S2 … …. ….. …… … 41 416 …………. …… S99
- 36.
- 37. Sprint at aGlance Discovery Session Release Planning Product Backlog Production Ready Features Burndown Sprint Backlog Sprint Planning Daily Scrum Work Sprint Review Sprint Retro Start Sprint Daly Scrum End Sprint Description Time boxed iteration that consists Of Sprint Planning, day to day Work , Daily Scrum, Sprint Review and Sprint Retrospective Involves • Isolated from further changes That would affect Sprint Goal • Work organized adaptively • 1- 4 Weeks Key Characteristics Duration • Team, Scrum Master, PO, SMEs Outputs: • Daily updates of Burndown charts or CFD • Potential shippable functionality • Other necessary items, as prioritized by Product Owner
- 38.
- 39. Sprint Backlog ata Glance Discovery Session Release Planning Product Backlog Production Ready Features Burndown Sprint Backlog Sprint Planning Daily Scrum Work Sprint Review Sprint Retro Start Sprint Daly Scrum End Sprint Description List of desired functionality and tasks for the team to get product Backlog items to done in the current sprint Managed By • Created at Sprint Planning • Updated throughout Sprint as tasks are added / removed Key Characteristics • Team, Scrum Master Outputs: • Prioritized User Stories & their constituent tasks • Task-level estimates (optional ) in hours • Other information necessary to understand the work at hand
- 40.
- 41. Sprint Planning ata Glance Description Meeting to elaborate, estimate and prioritize highest-value User Stories, creating Sprint Backlog Duration Attendees Meeting to elaborate, estimate and prioritize highest-value User Stories, creating Sprint Backlog Meeting to elaborate, estimate and prioritize highest-value User Stories, creating Sprint Backlog Discovery Session Release Planning Product Backlog Outputs: • Estimate and Prioritized User Stories • Updated Acceptance Criteria • Sprint backlog Tasks ready Production Ready Features Burndown Sprint Backlog Sprint Planning Daily Scrum Work Sprint Review Sprint Retro Start Sprint Daly Scrum End Sprint
- 42. Sprint Planning Preparation Description •Product Owners should arrive prepared to discuss top priority stories and ask any questions regarding alternative development paths • The Scrum Master should arrived prepared with capacity planning and logistical information, such as who is in, whose is out, who is working from home, expected velocity, etc. • Team members should have reviewed stories and determined initial estimates and questions about development scenarios • Acceptance criteria should be clear and well articulated • Depending on the needs of the team, other supporting material, like wireframes, should be created
- 43. From User Storiesto Tasks
- 44.
- 45. Daily Scrum ata Glance Description Daily meeting to inspect progress against Spring goal, to make adaptations that optimize the value of the next days work. Focused on making trade-offs, coordinating efforts and risk management. Duration 10-15 minutes Attendees Team, Scrum Master, optionally Product Owner and interested Stakeholders. Outputs: • Updated Schedules • Task Board Updated • Risks and Issues Identified • Informal follow up meetings (Sit-Downs) arranged Initial meeting Discovery session Release planning Product backlog Sprint planning Daily scrum Work Sprint Review Sprint Retro Ready features Start of Sprint Daily End of Sprint Sprint Sprint backlog Burndown
- 46.
- 47. Sprint Boards andTracking
- 48. Sprint – TaskBoard with WIP Limits
- 49.
- 50. Sprint Burndown: Summary Description Simpletool for Team to track progress during a Sprint Key Characteristics • Shows work remaining, not work completed • Traditionally have burned down task hours, many now burn down story points Ideal line shows the necessary angle for completion Managed by Team, ScrumMaster, Represents Progress versus Plan: • Below the line good • Above bad • Trend is also important
- 51.
- 52. Sprint Review ata Glance Outputs: • New features on Product Backlog • Reprioritized Product Backlog • Revised Team or Project Structure Initial meeting Discovery session Release planning Product backlog Sprint planning Daily scrum Work Sprint Review Sprint Retro Start of Sprint Daily End of Sprint Sprint Sprint backlog Burndown Description PO identifies what has been done versus plan, team demonstrates completed functionality, and attendees collaborate on what to do next. Duration 4 hours for 1 month Sprint, 2 hours for 2 week Sprint, etc. Attendees Team, ScrumMaster, optionally Product Owner, optionally Users and Interested Stakeholders. Ready features
- 53.
- 54.
- 55. Sprint Retrospective ata Glance Outputs: • New features on Product Backlog • Reprioritized Product Backlog • Revised Team or Project Structure Initial meeting Discovery session Release planning Product backlog Sprint planning Daily scrum Work Sprint Review Sprint Retro Start of Sprint Daily End of Sprint Sprint Sprint backlog Burndown Description SM guides team to inspect how last Sprint went (people, relationship, process and tools) to identify “pluses” and deltas to create a plan for change with the framework for upcoming Sprints. Duration 3 hours for 1 month Sprint, 1.5 hours for 2 week Sprint, etc. Attendees Team, ScrumMaster, optionally Product Owner. Ready features
- 56.
- 57.
- 58. Definition of Ready “Don'tlet anything that's not READY into your Sprint, and let nothing escape that's not DONE.” (Serge Beaumont about definition of ready) “ Backlog must be READY before taking into Sprint Software must be DONE at the end of the Sprint” (Jeff Sutherland in presentation) Serge Beaumont: ‘READY is when the team says: "Ah, we get it“’. ✓ Why? Business value ✓ What? Outcome vision ✓ How? Implementation strategy & cost ✓ User story have been estimated, backlog is prepared for 1,5 -2 sprints. ✓ Is the Granularity OK?
- 59. Sample Definition of“Done”
- 60.
- 61.