Let's Talk About Scrum

#Only90sKidsWillGetThis

Photo by Quino Al on Unsplash

A scrum (short for scrummage) is a method of restarting play in rugby that involves players packing closely together with their heads down and attempting to gain possession of the ball. For other uses, see Scrum (disambiguation).

Scrum may refer to: • Scrum (rugby), a method of restarting play in rugby • Scrum (media), an impromptu press conference, often held immediately outside an event • Autozam Scrum, a microvan and pickup truck sold in Japan by Mazda • “Scrum", a song on the album Diabolus in Musica by Slayer • Scrum (software), a variant of the agile methodology used for software development

Scrum (software) • The product is built in a series of fixed-length iterations called sprints that give teams a framework for shipping on a regular cadence. • Milestones–i.e., the end of a sprint–come frequently, bringing with them a feeling of tangible progress. • Short iterations reinforce the importance of good estimation and fast feedback from tests. Empirical data

Justin Searls @searls To be clear, apathy isn't a moral failing— it's actually a rational coping mechanism in unhealthy environments. Want an apathetic software team? Pressure them to meet aggressive arbitrary deadlines or exert undue control over how they do their work

Scrum Values • Transparency: nothing happens in the dark. The product backlog is visible, estimates are shared, velocity is tracked, definition of done is clear, etc. • Inspection: Inspect Scrum artifacts frequently, but not so frequently it gets in the way of work. • Adaption: If something isn’t working, adjust course as quickly as possible.

— meet the — Scrum Team

— the — Dev Team — the — Scrum Master The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. — the — Product Owner photo by rawpixel on unsplash

re ach ing : h c t a c e H e re's t h m ing” s t age is r t h e “p e r f o if a te am's im p o s s ible s ch a ng ing! eep m ak e-up k image credit: Atlassian We’ll dig into those in a moment, but first I want to talk about how teams become effective over time.

photo by rawpixel on unsplash

— the — Product Owner photo by rawpixel on unsplash

Product Owner • Champion of their product • One person, not a committee • Focused on understanding business and market requirements, then prioritizing the work to be done by the Dev Team accordingly • Responsible for managing product backlog • Not a project manager! Not a project manager: Not managing the status of the program. They focus on ensuring the dev team delivers the most value to the business.

photo by rawpixel on unsplash

— the — Dev Team photo by rawpixel on unsplash

Development Team • Champions of sustainable development practices • Consists of 3-9 professionals • Responsible for planning the sprint and delivering a potentially releasable increment of “Done” work • Self-organizing: No one (not even the Scrum Master) tells the Dev Team how to work • Cross-functional: Has all competencies needed to do the work without depending on non-team members

photo by rawpixel on unsplash

— the — Scrum Master photo by rawpixel on unsplash

Scrum Master • Champion of process within their team • Coach the team and the business on Scrum & look for ways to fine-tune their process • Resolve impediments for the Dev Team, insulating them from external disruptions when possible • Defend against a common Scrum anti-pattern: changing a sprint's scope after it has begun • Also not a project manager! Product owners will sometimes ask, "Can't we get this one more super-important little thing into this sprint?" But keeping scope air tight reinforces good estimation and product planning–not to mention fends off a source of disruption to the development team.

Scrum Master • What happens when there’s no dedicated Scrum Master? • Avoid conflicts of interest — Product Owners should not act as Scrum Masters • Rotating the Scrum Master role through the Dev Team can inject fresh ideas • Best to worst: Dedicated Scrum Master, Shared Scrum Masters, Engineer Scrum Master, No Scrum Master

— the — Scrum Rituals aka Ceremonies. Now that we understand the team, let’s talk rituals.

Scrum Rituals • Prescribed events create regularity and minimize the need for meetings not defined in Scrum • All events are time-boxed • Other than the sprint itself, each event is a formal opportunity to inspect and adapt

The Sprint A fixed length of work during which a “Done,” useable, and potentially releasable product increment is created.

The Sprint • Once started, no changes that would endanger the sprint goal • That includes adding user stories or changing sprint length • Sprint cancellations are traumatic to the Scrum team, and are very uncommon When a Sprint is cancelled, any completed and "Done" Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

How Long is a Sprint? • Sprint length can range from 1–4 weeks • 2 weeks is pretty standard • You can get more done in a longer sprint, but you’re less capable of reacting to changes • Keeping sprint length consistent gives the Dev Team critical feedback on estimation & delivery process, makes forecasts increasingly accurate over time.

Product Backlog Grooming The team reviews and estimates user stories in the product backlog

Product Backlog Grooming • Duration: 1 hour / week of sprint • Happens: Could be anytime, but often first day of sprint, or alternate Mondays • Attendees: scrum team • Purpose: The Product Owner gets help with the product backlog.

What’s a Product Backlog? An ordered list of user stories for everything known to be needed in the product • Single source of requirements for any changes to be made to the product • Product Owner is responsible for the product backlog, including its content, availability, and ordering • A product backlog is never complete

What are User Stories? • As a {type of user}, I want {functionality} so that I {receive benefit} • Sketched out by Product Owner • Should describe a problem, not prescribe a solution • Dev Team helps refine • Can this be done? Do we need more information? Should it be broken into smaller stories? As a customer, I want to be able to create an account so that I can see the purchases I made in the last year to help me budget for next year.

How Do We Estimate? • Dev Team plays planning poker to assign story points • Points rate the relative effort of work, not time to complete • Estimated relative to other well-understood work. “Is this more or less complicated than that story?” • Abstraction avoids the “Architect can do it in 2 hours, but the intern needs a full week” problem • Estimates will be inaccurate until the team establishes a common baseline after a few sprints

Sprint Planning The team determines their sprint capacity and pulls stories from the product backlog

Sprint Planning • Duration: 2 hours / week of sprint (new teams may need more time) • Happens: first day of the sprint • Attendees: scrum team • Purpose: The Dev Team plans their work with guidance from the Product Owner

Sprint Planning • Capacity for the sprint is determined by reviewing velocity • User stories are pulled in order from the top of the product backlog • The team breaks user stories into tasks for the sprint backlog • Define a sprint goal to provide context and guidance to the team

What’s a Sprint Backlog? An ordered list of tasks created from user stories accepted into the current sprint • Stories must be estimated and contain clear acceptance criteria • Should not change once the sprint starts, because the Dev Team is making a informed commitment to deliver this body of work. • What about bugs and P0 interruptions? (they’re going to happen!)

What is Velocity? A measure of the amount of work a Scrum team can complete during a single Sprint • Calculated as a rolling average of the story points completed in previous sprints • It takes several sprints before a useful velocity metric can be determined • Velocity is only for planning! Team success should be based on value delivered.

image credit: Atlassian

Estimation statistic: The y-axis displays the statistic used for estimating stories. 2. Commitment: The gray bar for each sprint shows the total estimate of all issues in the sprint when it begins. 3. Completed: The green bar in each sprint shows the total completed estimates when the sprint ends. 4. Sprints: The x-axis displays the last several sprints completed by the team.

Daily Scrum a.k.a. Standup The Dev Team plans their work for the next 24 hours and checks progress towards sprint goal

Daily Scrum • Duration: 15 min timeboxed • Happens: every day • Attendees: Dev Team, Scrum Master. Product Owner optional. • If others are present, the Scrum Master ensures that they do not disrupt the meeting. • Purpose: The Dev Team checks their progress toward the sprint goal If others are present, the Scrum Master ensures that they do not disrupt the meeting.

Daily Scrum • Check progress by: • Answer the three questions • Review the burndown chart • This is a meeting for the Dev Team, not a detailed status report for management • Blockers should be escalated to Scrum Master

What are the Three Questions? • What did I do yesterday that helped the Dev Team meet the sprint goal? • What will I do today to help the Dev Team meet the sprint goal? • Do I see any impediment that prevents me or the Dev Team from meeting the sprint goal? • This is not “justify your salary” time. Answers should be relevant to the sprint goal. This is not “justify your salary” time. No one needs to know every little thing you did. Answers should be relevant to the sprint goal.

What’s a Burndown Chart? Shows the work completed over time compared to an ideal trend line • Reviewing this chart can be a useful tool to see if the Dev Team is on-track to complete their work • If the burndown line extends beyond the trend line, the team may be falling behind their goal • If the burndown line makes steep drops, the team should work on breaking stories into smaller tasks

image credit: Atlassian

Sprint Review An informal demo of what was achieved by the team to the Product Owner and other stakeholders

Sprint Review • Duration: 30 min / week of sprint • Happens: last day of the sprint • Attendees: scrum team, key stakeholders invited by Product Owner • Purpose: Demonstrate work and get feedback

Sprint Review • Focus on the product, not the process • Work should be fully demonstrable and meet the team's definition of “Done” to be considered complete and ready to showcase in the review • Celebrate success • Gather feedback, which should channel back into the product backlog

Sprint Retrospective A review of what did and didn't go well with actions to make the next sprint better.

Sprint Retrospective • Duration: 30 min / week of sprint • Happens: last day of the sprint • Attendees: scrum team (no management!) • Purpose: Review and improve process

Sprint Retrospective • Focus on improving process, not the product • Not a time for complaints without action • Reflect on what went well during the sprint so the team can continue to focus on those areas • Find out what's not working and use the time to find creative solutions and develop an action plan

— let’s — Recap

image credit: scrum.org

Scrum Values • Transparency: nothing happens in the dark. The product backlog is visible, estimates are shared, velocity is tracked, definition of done is clear, etc. • Inspection: Inspect Scrum artifacts frequently, but not so frequently it gets in the way of work. • Adaption: If something isn’t working, adjust course as quickly as possible.

Learn More • The Scrum Guide https://www.scrumguides.org/ • Scrum Rituals, Summarized https://wp.me/p27LsI-3G • Atlassian Scrum Guide https://www.atlassian.com/agile/scrum Scott Vandehey — spaceninja.com — @spaceninja

#Only90sKidsWillGetThis