Scrum for Teams

Book description

Scrum is an agile framework for completing complex projects. This book gives examples, tools, and tricks to do Scrum well.

For each trick it is explained why it helps. The practices themselves may be worth trying, but by understanding why it works the readers will be able to come up with their own ideas that work better in their organization and situation. All the practical examples in this book have helped someone, somewhere to become a part of a better Scrum team.

Scrum's motto is: Inspect and Adapt; change small things one at a time and see what works. Scrum is not done by project leaders or managers, but really by the teams-to succeed in an organization, the teams must do Scrum well. If the teams do Scrum well, the whole organization will benefit from it. Scrum helps a team self-organize, which fits in well with developers, who usually don't like to be micromanaged. At the same time, Scrum can scale: Self-organized teams work together well, and one manager doesn't have to manage all the people.

The lessons from this book help Scrum teams develop into autonomous, proud, and independent teams. Often teams fail to become powerful enough to change the organization, so they cannot perform to their full potential. A good team can lead the stakeholders into trusting them. They will then make plans based on the team's release planning instead of making roadmaps out of thin air, and thus make the organization much more predictable.

Table of contents

  1. Cover
  2. Half Title Page
  3. Title Page
  4. Copyright Page
  5. Contents
  6. Preface
  7. Acknowledgments
  8. Chapter 1 Introduction
  9. Chapter 2 What Is Scrum?
    1. 2.1 The Product
      1. 2.1.1 The Product Owner
      2. 2.1.2 The Product Backlog
    2. 2.2 The Process
      1. 2.2.1 The Scrum Master
      2. 2.2.2 The Sprint Planning
      3. 2.2.3 The Sprint Backlog
      4. 2.2.4 The Sprint and the Stand-Up Meeting
      5. 2.2.5 The Scrum Board
      6. 2.2.6 The Sprint Demo
      7. 2.2.7 The Retrospective Meeting
    3. 2.3 Measuring Progress
    4. 2.4 Summary
  10. Chapter 3 Make the Most of Stand-Ups
    1. 3.1 Guard Your Time
      1. 3.1.1 Start on Time
      2. 3.1.2 Don’t Run Late
    2. 3.2 Stay on Topic
      1. 3.2.1 Stick to the Three Questions
      2. 3.2.2 Be Prepared
      3. 3.2.3 The Talking Stick
    3. 3.3 Explain Clearly, Listen Carefully
      1. 3.3.1 Talk to the Team
      2. 3.3.2 Make the Team Understand
      3. 3.3.3 Listen, Understand, Remember
    4. 3.4 Stand-Ups: Getting It Right
  11. Chapter 4 Everything on the Board
    1. 4.1 The Accessible Board
      1. 4.1.1 Large and Near
      2. 4.1.2 Low-Tech over Hi-Tech
      3. 4.1.3 Use Colors
      4. 4.1.4 The Board Has Two Audiences
    2. 4.2 Everything Flows
      1. 4.2.1 Use Names on Tasks
      2. 4.2.2 Use Dots for Days Spent on Tasks
    3. 4.3 Shortest Path from To Do to Done
      1. 4.3.1 Don’t Use Extra Columns
    4. 4.4 But There Is More to Remember
      1. 4.4.1 Unplanned Work
      2. 4.4.2 Impediments
      3. 4.4.3 Next
      4. 4.4.4 Issues
      5. 4.4.5 Improvement Items
    5. 4.5 The Scrum Board: Getting It Right
  12. Chapter 5 Planning Is Half the Work
    1. 5.1 Planning the Planning
      1. 5.1.1 Preparing the Session
      2. 5.1.2 User Stories
      3. 5.1.3 Ready (or READY)
    2. 5.2 Size Matters
      1. 5.2.1 Establish the Team’s Velocity
      2. 5.2.2 Use Story Points Instead of Days
      3. 5.2.3 Let’s Look at a Detailed Example
      4. 5.2.4 Use a Burn-Down Chart
      5. 5.2.5 What’s the Use of Velocity for the Team?
      6. 5.2.6 Size before the Planning Meeting
    3. 5.3 Sizing Is Not Easy
      1. 5.3.1 Size with the Whole Team
      2. 5.3.2 Planning Poker
      3. 5.3.3 Resize Unfinished Work
      4. 5.3.4 Break It Down!
      5. 5.3.5 Task Your Stories
      6. 5.3.6 Estimating Tasks
    4. 5.4 Team Commitment
    5. 5.5 Planning: Getting It Right
  13. Chapter 6 Practices Make Perfect
    1. 6.1 Programming for Change
      1. 6.1.1 Automated Testing
      2. 6.1.2 Test-Driven Development
      3. 6.1.3 Continuous Integration
      4. 6.1.4 Refactoring
      5. 6.1.5 Emergent Architecture
    2. 6.2 A Team That Works as a Team
      1. 6.2.1 Code Is Not Private
      2. 6.2.2 Pair Programming Instead of Code Reviews
      3. 6.2.3 Review for Information
      4. 6.2.4 Shared Ownership
    3. 6.3 Team Organization
      1. 6.3.1 Multidisciplinary Teams
      2. 6.3.2 But There Really Is Not Enough to Do!
    4. 6.4 Documentation
      1. 6.4.1 Keep It Small
      2. 6.4.2 Know What to Document
      3. 6.4.3 Iterate, Iterate
    5. 6.5 Team Work: Getting It Right
  14. Chapter 7 Demo, Demo
    1. 7.1 Don’t Move Deadlines
      1. 7.1.1 Deadlines Are Seldom Internal
      2. 7.1.2 Velocity Needs a Timebox
      3. 7.1.3 It’s Fun to Finish Things
    2. 7.2 Don’t Let Deadlines Woosh By
      1. 7.2.1 Minimize Work in Progress
      2. 7.2.2 Don’t Commit to Too Much Work
    3. 7.3 On with the Show
      1. 7.3.1 It Starts at the Planning
      2. 7.3.2 Make a Demo Plan
      3. 7.3.3 Avoid PowerPoint
      4. 7.3.4 Wiki Pages for Demos and Sprints
      5. 7.3.5 Shorter Is Better
      6. 7.3.6 Let’s Look at a Detailed Example Again
    4. 7.4 Sprint Flow
    5. 7.5 Sprint Demos: Getting It Right
  15. Chapter 8 Look Back!
    1. 8.1 Learn from the Past
      1. 8.1.1 Party Time!
      2. 8.1.2 Identify Problems You Had
      3. 8.1.3 No Blaming or Fingerpointing
      4. 8.1.4 Repeat What You Did Right
    2. 8.2 Every Beginning Is Difficult
      1. 8.2.1 But I Don’t Like Retrospectives!
      2. 8.2.2 Forming, Storming, Norming, Performing
      3. 8.2.3 Just the Team
    3. 8.3 Get It on the Table
      1. 8.3.1 Do the Rounds
      2. 8.3.2 Timeline Lists
      3. 8.3.3 The Sailboat Retro and Other Questions
      4. 8.3.4 Writing Apart
      5. 8.3.5 Dot Voting
    4. 8.4 Inspect and Adapt
      1. 8.4.1 Digging Down
      2. 8.4.2 Improvement Items
      3. 8.4.3 Keep It to Yourself
      4. 8.4.4 Team Consensus
    5. 8.5 Retrospectives: Getting It Right
  16. Chapter 9 Done, Done, Done, Done, Done
    1. 9.1 Definition of Done
      1. 9.1.1 The More Done, the Better
      2. 9.1.2 Done Includes Testing
    2. 9.2 What Sizes Are Not
      1. 9.2.1 Velocity Is Different for Each Team
      2. 9.2.2 Focus Factor
      3. 9.2.3 Universal Velocity Is a Myth
      4. 9.2.4 Don’t Push It
    3. 9.3 Don’t Plan for the Unknown
      1. 9.3.1 Dealing with Bugs
      2. 9.3.2 Planned versus Unplanned
      3. 9.3.3 Your Velocity Will Create Buffer Time
      4. 9.3.4 Too Much to Handle
      5. 9.3.5 Find the Source
    4. 9.4 Sharpening the Saw
      1. 9.4.1 Invest in Tools
      2. 9.4.2 Firefighters
      3. 9.4.3 Component Teams versus Feature Teams
    5. 9.5 The End User’s Done: Getting It Right
  17. Chapter 10 Power to the Team
    1. 10.1 The Product Owner’s Role
      1. 10.1.1 What the Product Owner Does
      2. 10.1.2 Velocity Is the Only Performance Measurement
      3. 10.1.3 Release Planning
      4. 10.1.4 Own and Share the Release Plan
      5. 10.1.5 Technical Stories
    2. 10.2 The Scrum Master’s Role
      1. 10.2.1 What the Scrum Master Does
      2. 10.2.2 Say “No” to Disturbance
      3. 10.2.3 Never Commit to Too Much Work
    3. 10.3 The Team’s Role
      1. 10.3.1 Just a Team, or a Scrum Team?
      2. 10.3.2 Be Responsible
      3. 10.3.3 Maximum Sustainable Pace
      4. 10.3.4 Continuous Improvement
      5. 10.3.5 Keep the Team Together
    4. 10.4 Scrum: Getting It Right
    5. 10.5 Have Fun!
  18. Bibliography
  19. Index

Product information

  • Title: Scrum for Teams
  • Author(s): Dion Nicolaas
  • Release date: September 2018
  • Publisher(s): Business Expert Press
  • ISBN: 9781948198448