book

Scrum for Teams

Name: Scrum for Teams
Author: Dion Nicolaas
ISBN: 9781948198448

by Dion Nicolaas

September 2018

Intermediate to advanced

146 pages

3h 1m

English

Business Expert Press

Read now

Unlock full access

Cover
Half Title Page
Title Page
Copyright Page
Contents
Preface
Acknowledgments
Chapter 1 Introduction
Chapter 2 What Is Scrum?
2.1 The Product2.1.1 The Product Owner2.1.2 The Product Backlog2.2 The Process2.2.1 The Scrum Master2.2.2 The Sprint Planning2.2.3 The Sprint Backlog2.2.4 The Sprint and the Stand-Up Meeting2.2.5 The Scrum Board2.2.6 The Sprint Demo2.2.7 The Retrospective Meeting2.3 Measuring Progress2.4 Summary
Chapter 3 Make the Most of Stand-Ups
3.1 Guard Your Time3.1.1 Start on Time3.1.2 Don’t Run Late3.2 Stay on Topic3.2.1 Stick to the Three Questions3.2.2 Be Prepared3.2.3 The Talking Stick3.3 Explain Clearly, Listen Carefully3.3.1 Talk to the Team3.3.2 Make the Team Understand3.3.3 Listen, Understand, Remember3.4 Stand-Ups: Getting It Right

Chapter 4 Everything on the Board
4.1 The Accessible Board4.1.1 Large and Near4.1.2 Low-Tech over Hi-Tech4.1.3 Use Colors4.1.4 The Board Has Two Audiences4.2 Everything Flows4.2.1 Use Names on Tasks4.2.2 Use Dots for Days Spent on Tasks4.3 Shortest Path from To Do to Done4.3.1 Don’t Use Extra Columns4.4 But There Is More to Remember4.4.1 Unplanned Work4.4.2 Impediments4.4.3 Next4.4.4 Issues4.4.5 Improvement Items4.5 The Scrum Board: Getting It Right
Chapter 5 Planning Is Half the Work
5.1 Planning the Planning5.1.1 Preparing the Session5.1.2 User Stories5.1.3 Ready (or READY)5.2 Size Matters5.2.1 Establish the Team’s Velocity5.2.2 Use Story Points Instead of Days5.2.3 Let’s Look at a Detailed Example5.2.4 Use a Burn-Down Chart5.2.5 What’s the Use of Velocity for the Team?5.2.6 Size before the Planning Meeting5.3 Sizing Is Not Easy5.3.1 Size with the Whole Team5.3.2 Planning Poker5.3.3 Resize Unfinished Work5.3.4 Break It Down!5.3.5 Task Your Stories5.3.6 Estimating Tasks5.4 Team Commitment5.5 Planning: Getting It Right
Chapter 6 Practices Make Perfect
6.1 Programming for Change6.1.1 Automated Testing6.1.2 Test-Driven Development6.1.3 Continuous Integration6.1.4 Refactoring6.1.5 Emergent Architecture6.2 A Team That Works as a Team6.2.1 Code Is Not Private6.2.2 Pair Programming Instead of Code Reviews6.2.3 Review for Information6.2.4 Shared Ownership6.3 Team Organization6.3.1 Multidisciplinary Teams6.3.2 But There Really Is Not Enough to Do!6.4 Documentation6.4.1 Keep It Small6.4.2 Know What to Document6.4.3 Iterate, Iterate6.5 Team Work: Getting It Right
Chapter 7 Demo, Demo
7.1 Don’t Move Deadlines7.1.1 Deadlines Are Seldom Internal7.1.2 Velocity Needs a Timebox7.1.3 It’s Fun to Finish Things7.2 Don’t Let Deadlines Woosh By7.2.1 Minimize Work in Progress7.2.2 Don’t Commit to Too Much Work7.3 On with the Show7.3.1 It Starts at the Planning7.3.2 Make a Demo Plan7.3.3 Avoid PowerPoint7.3.4 Wiki Pages for Demos and Sprints7.3.5 Shorter Is Better7.3.6 Let’s Look at a Detailed Example Again7.4 Sprint Flow7.5 Sprint Demos: Getting It Right
Chapter 8 Look Back!
8.1 Learn from the Past8.1.1 Party Time!8.1.2 Identify Problems You Had8.1.3 No Blaming or Fingerpointing8.1.4 Repeat What You Did Right8.2 Every Beginning Is Difficult8.2.1 But I Don’t Like Retrospectives!8.2.2 Forming, Storming, Norming, Performing8.2.3 Just the Team8.3 Get It on the Table8.3.1 Do the Rounds8.3.2 Timeline Lists8.3.3 The Sailboat Retro and Other Questions8.3.4 Writing Apart8.3.5 Dot Voting8.4 Inspect and Adapt8.4.1 Digging Down8.4.2 Improvement Items8.4.3 Keep It to Yourself8.4.4 Team Consensus8.5 Retrospectives: Getting It Right
Chapter 9 Done, Done, Done, Done, Done
9.1 Definition of Done9.1.1 The More Done, the Better9.1.2 Done Includes Testing9.2 What Sizes Are Not9.2.1 Velocity Is Different for Each Team9.2.2 Focus Factor9.2.3 Universal Velocity Is a Myth9.2.4 Don’t Push It9.3 Don’t Plan for the Unknown9.3.1 Dealing with Bugs9.3.2 Planned versus Unplanned9.3.3 Your Velocity Will Create Buffer Time9.3.4 Too Much to Handle9.3.5 Find the Source9.4 Sharpening the Saw9.4.1 Invest in Tools9.4.2 Firefighters9.4.3 Component Teams versus Feature Teams9.5 The End User’s Done: Getting It Right
Chapter 10 Power to the Team
10.1 The Product Owner’s Role10.1.1 What the Product Owner Does10.1.2 Velocity Is the Only Performance Measurement10.1.3 Release Planning10.1.4 Own and Share the Release Plan10.1.5 Technical Stories10.2 The Scrum Master’s Role10.2.1 What the Scrum Master Does10.2.2 Say “No” to Disturbance10.2.3 Never Commit to Too Much Work10.3 The Team’s Role10.3.1 Just a Team, or a Scrum Team?10.3.2 Be Responsible10.3.3 Maximum Sustainable Pace10.3.4 Continuous Improvement10.3.5 Keep the Team Together10.4 Scrum: Getting It Right10.5 Have Fun!
Bibliography
Index

Content preview from Scrum for Teams

Index

Agile architecture. See Emergent architecture

Automated testing, 55–56

Buffer time, creating, 102–103

Build server, 61

Burn-down chart, 9, 41–42

Component tests, 56

Continuous integration, 57

Crisis management, 12

Deadlines, moving, 69–70

Definition of Done, 96–98

Definition of READY, 38

Documentation, 64–65

iteration, 65

keeping it small, 64

locally stored word documents, using, 69

what to document, knowing, 64–65

Dot voting, 87–88

Emergent architecture, 58

End-to-end tests, 56

End user’s done

component versus feature teams, 105–106

dealing with bugs, 101–102

Definition of Done, 96–98

done includes testing, 97–98

finding source, 104

firefighters, 105

focus factor, 99

getting it right, ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781948198448

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Scrum for Teams

by Dion Nicolaas

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.