The Professional Scrum Master Guide E-Book

Fred Heath

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 227

Veröffentlichungsjahr: 2021

Beschreibung

This book demonstrates the real-world applications of Scrum in a variety of scenarios, all with practical examples. You’ll understand why the structure of your Scrum team matters, and how to create and manage sprint and product backlogs. Each chapter concludes with relevance to the exam, reinforcing what you’ve learned as you work through the book and making sure you have an edge when it comes to earning your certificate.
The statements made and opinions expressed herein belong exclusively to Packt Publishing Ltd and are not shared by or represent the viewpoint of Scrum.org. This training does not constitute an endorsement of any product, service or point of view. Scrum.org makes no representations, warranties or assurances of any kind, express or implied, as to the completeness, accuracy, reliability, suitability, availability or currency of the content contained in this presentation or any material related to this presentation. In no event shall Scrum.org, its agents, officers, employees, licensees or affiliates be liable for any damages whatsoever (including, without limitation, damages for loss of profits, business information, or loss of information) arising out of the information or statements contained in the training. Any reliance you place on such content is strictly at your own risk.

Leseprobe

The Professional Scrum Master Guide

The unofficial guide to Scrum with real-world projects

Fred Heath

The Professional Scrum Master Guide

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Kunal Chaudhari

Publishing Product Manager: Shweta Bairoliya

Senior Editor: Storm Mann

Content Development Editor: Nithya Sadanandan

Technical Editor: Gaurav Gala

Copy Editor: Safis Editing

Project Coordinator: Deeksha Thakkar

Proofreader: Safis Editing

Indexer: Vinayak Purushotham

Production Designer: Ponraj Dhandapani

First published: June 2021

Production reference: 3230424

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80020-556-7

www.packtpub.com

To my wife, Julie, and my daughter, Sophia. They make it all worthwhile.

- Fred Heath

Contributors

About the author

Fred Heath is a senior software engineer with 24 years' experience. Fred has worked at every level of the software development lifecycle and has used a multitude of technologies, platforms, and programming languages. His professional interests include programming in Ruby and Elixir, behavior-driven development, and semantic analysis.

Fred holds B.Eng and M.Sc. degrees (Cardiff University) and is a Microsoft Certified Professional (SQL Server 2000), a certified Professional Scrum Master (PSM-I), and a certified Professional Agile Leader (PAL-I). He enjoys blogging about software development topics and is a frequent speaker at conferences and meetups.

Fred has also authored Managing Software Requirements the Agile Way (Packt, 2020).

About the reviewer

Tarun Gupta is a certified Scrum Master with around 14 years of experience in IT. He has several credentials, including PMI-ACP, PSM II, CSM, ASM, SAFe Agilist 4.5, and PMP.

He started his career as a QA engineer in the telecom domain after graduating with a master's degree in computer applications (MCA) from Pune University in 2007. He has helped teams to transition from Waterfall to Agile and has coached them to achieve maximum efficiency and the highest product value by successfully completing sprints.

Tarun believes that Scrum has some important values, such as focus, commitment, openness, respect, and courage, that can be adopted in life to be more productive and successful. He believes that any organization can be Agile if there is transparency, continuous improvement, continuous delivery, and adaptability.

Table of Contents

Preface

Section 1: The Scrum Framework

1

Introduction to Scrum

What is Agile software development?

What is Scrum?

The value of an iterative and incremental approach

The waterfall legacy

Iterative and incremental software development

Why should you choose Scrum?

Introducing PSM assessments

Scrum organizations and their history

The PSM I assessment

Summary

Further reading

2

Scrum Theory and Principles

The foundation of Scrum

The pillars of empiricism

Inspection

Adaptation

Transparency

The Scrum values

The House of Scrum

Summary

Questions

3

The Scrum Team

Identifying a Scrum Team

Defining a Scrum Team

Introducing the Scrum Master

Scrum Master responsibilities

Things outside the Scrum Master realm

Scrum Master Q&A

Working with the Product Owner

Product Owner responsibilities

Things outside the Product Owner realm

Product Owner Q&A

Getting acquainted with the Developers

The Developers are self-managing

The Developers are a cross-functional group

Developer structure

Developer responsibilities

Things outside the Developers' realm

Developer Q&A

Summary

Questions

4

Scrum Events

Getting ready to Sprint

Deciding on the Sprint duration

Setting the Sprint Goal

Defining Done as working and potentially shippable software

Starting the Sprint with Sprint Planning

Sprint Planning for the Scrum Master

Sprint Planning for the Product Owner

Sprint Planning for the Developers

Keeping on the right track with the Daily Scrum

Inspecting the product during the Sprint Review

Inspecting the team with the Sprint Retrospective

Summary

Questions

Further reading

5

Scrum Artifacts

Understanding the value of Scrum Artifacts

Creating and managing the Product Backlog

Making a commitment – the Product Goal

Creating Backlog items as user stories

Creating Product Backlog items as features

Refining the Product Backlog

Creating and managing the Sprint Backlog

Making a commitment – the Sprint Goal

Planning for the Sprint

Producing a Product Increment

Making a commitment – Definition of Done

Summary

Questions

Further reading

Section 2: Scrum in Action

6

Planning and Estimating with Scrum

Managing the art of estimation

Choosing an estimation scale

Creating a baseline

Playing Planning Poker

Estimating backlog items using the bucket method

Planning ahead with the product roadmap

Envisioning the product journey with a product roadmap

Forecasting with velocity and burn charts

Calculating team velocity

Burndown charts

Burnup charts

Summary

Questions

Further reading

7

The Sprint Journey

Refining the Product Backlog

Learning how to apply order to the Product Backlog

Scrum Master duties for Product Backlog refinement

Preparing for the first Sprint

Tracking progress with a Scrum Board

What to do when the Sprint Goal is not achieved

Managing defects

Dealing with defects in the current Sprint

Dealing with defects from previous Sprints

Canceling the Sprint

What to do with the Sprint Backlog items

How to wrap up a canceled Sprint

Summary

Questions

Further reading

8

Facets of Scrum

Learning software development practices for Scrum

Source control model for continuous integration

Continuous delivery and continuous deployment

Leveraging testing methods for Scrum

Applying Scrum to remote teams

Managing technical debt

How is technical debt created?

How to pay back technical debt

Scaling Scrum

Summary

Questions

Section 3: The PSM Certification

9

Preparing for the PSM I Assessment

Getting ready for the PSM I assessment

Fundamental information about the assessment

What you will need to take the assessment

How to prepare for the assessment

Taking the PSM I assessment

What happens after the assessment

PSM I mock assessment

Mock assessment answers

Summary

Assessments

Other Books You May Enjoy

Index

Preface

The Scrum framework was conceived in the late 1980s to counteract the formal, rigid, and stagnating software development methodologies prevalent at the time. The Scrum framework was formalized in the mid-1990s and its founders, Jeff Sutherland and Ken Schwaber, were instrumental in the creation of the Agile Manifesto and the subsequent spread of the Agile development movement. Scrum quickly became the most popular Agile framework, with huge adoption in both small businesses and the enterprise world. Part of the popularity of Scrum is its adaptability. The Scrum Guide keeps getting updated every few years to reflect current thinking and practices. Scrum.org also offers an impressive array of Scrum-related resources and certifications, one of which we'll be addressing in this book.

This book aims to teach people new to, or inexperienced with, Scrum all about the Scrum framework from a practical as well as a theoretical perspective. The book consists of two parts. In the first five chapters, we will cover the Scrum fundamentals. The theory and principles of Scrum will be digested, before moving on to cover the Scrum Team, Events, and Artifacts. The second part will focus on more practical knowledge, by examining practices and methods used by Scrum Teams in the real world. We will learn how to plan and estimate in Scrum, how to monitor progress and deal with different situations within the Sprint, best practices for infrastructure and testing, and how to manage eventualities such as technical debt or remote working. Every chapter closes with a short quiz to reinforce the knowledge gained.

Finally, the last chapter is entirely dedicated to the PSM I assessment. It offers practical advice on what to do before, during, and after the assessment exam to maximize your chances of success. This is capped with a mock assessment questionnaire, which closely represents the actual PSM I assessment.

Who this book is for

This book is for professionals who want to build a strong foundation in Scrum practices and development. Project managers, product owners, product managers across various industries, sectors, and departments, software architects, developers, coders, and testers looking to achieve PSM certification will also find this book helpful.

It may also serve as a useful source of updated knowledge for existing Scrum Masters or developers who are not fully cognizant of the 2020 Scrum Guide revisions. Having existing Scrum, or other Agile methodology, knowledge is not a prerequisite for reading this book.

What this book covers

Chapter 1, Introduction to Scrum, presents you with the history and motivation behind Scrum, its value as a development framework, and introduces you to the PSM I assessment.

Chapter 2, Scrum Theory and Principles, shares knowledge of the fundamental concepts behind Scrum, its values, and its pillars. It also highlights the value and effect of these concepts in applying Scrum successfully.

Chapter 3, The Scrum Team, analyzes the role and responsibilities of the Scrum Master, Product Owner, and Developers and their interactions within the Scrum development lifecycle.

Chapter 4, Scrum Events, explains the significance of the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective events and their application and utility within the Scrum development lifecycle.

Chapter 5, Scrum Artifacts, details the Product Backlog, the Sprint Backlog, and the Product Increment, as well as the commitments undertaken for each of these Artifacts. The inter-dependencies of these Artifacts are also covered.

Chapter 6, Planning and Estimating with Scrum, delves into the world of measuring, estimating, planning, and forecasting. You will learn how to calculate your team's velocity, create a product roadmap, and measure your progress with burn-up and burn-down charts.

Chapter 7, The Sprint Journey, imparts practical advice and techniques for day-to-day working during the Sprint. Product Backlog refinement is explained, as well as how to use a Scrum Board in different scenarios, manage defects, and what to do if the Sprint is canceled.

Chapter 8, Facets of Scrum, covers best practices to use when working with Scrum. The importance of a CI/CD pipeline as testing levels is examined in detail. Techniques for managing technical debt, working remotely, and scaling Scrum are also explained.

Chapter 9, Preparing for the PSM I Assessment, is a short chapter mainly hosting 25 quiz questions summarizing the knowledge contained in this book, helping you to prepare for taking the PSM I assessment exam. Practical advice on how to prepare for the exam, and what to do during and after, is also given.

Download the color images

We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here:

https://static.packt-cdn.com/downloads/9781800205567_ColorImages.pdf

Conventions used

There are a number of text conventions used throughout this book.

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "Integrate the gadget database in the Show Gadgets page."

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.

Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you've read The Professional Scrum Master Guide, we'd love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we're delivering excellent quality content.

Section 1:The Scrum Framework

In this part, you will learn why and when to use Scrum and explore the components of the Scrum framework.

This section comprises the following chapters:

Chapter 1, Introduction to ScrumChapter 2, Scrum Theory and PrinciplesChapter 3, The Scrum TeamChapter 4, Scrum EventsChapter 5, Scrum Artifacts

1

Introduction to Scrum

In this chapter, we will introduce Scrum as an Agile framework, defining both Agile and Scrum and discussing the history and principles behind them. We will then explain the value of using the iterative and incremental development lifecycle prescribed by Scrum and describe some of the other Scrum benefits. We will close this chapter by introducing the PSM assessments and talking about the PSM I assessment in more detail. We will cover the following topics:

What is Agile software development?What is Scrum?The value of an iterative and incremental approachWhy should you choose Scrum?Introducing PSM I assessment

By the end of this chapter, you should know what Agile development and the Scrum framework are, how they improve and optimize software development, and what the PSM assessment involves. Let's start by understanding what people mean by the term Agile.

What is Agile software development?

Anyone who has been working in software development over the last 10 years or so will have at least heard of the term Agile. People often talk about doing Agile or being Agile but, beyond a cool-sounding buzzword, what is Agile really all about? Well, to answer that question, we need to look at the origins of Agile software development.

Back in the late 1990s, many senior software developers and industry leaders, fed up with the static and inflexible software development methodologies prevalent at the time, were already experimenting with more flexible and responsive techniques and approaches. In 2000 and 2001, a small group of these influencers met up to discuss these methods and techniques. The unifying theme behind this effort was a desire to be able to quickly deliver working software to end users and to get rapid feedback on the software's impact and scope. In the forthcoming years, methodologies developed under this philosophy came to be known under the umbrella term of Agile.

The Agile philosophy is best captured in the Agile Manifesto (2001), which identifies the following values:

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

The Agile Manifesto clearly states that while there is value in the items on the right of this list, we value the items on the left more. So, it is not an abandonment of the old values, but a realization that some new values (individuals and interactions, working software, collaboration, adapting to change) are far more relevant in the modern software development world. In addition, they also came up with a set of principles (see Principles behind the Agile Manifesto in the Further reading section), emphasizing continuous delivery, frequent feedback, personal interactions, and much more. These principles are as follows:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from every couple of weeks to every couple of months, with a preference for a shorter timescale.Businesspeople and developers must work together daily throughout the project.Build projects around motivated individuals.Give them the environment and support they need and trust them to get the job done.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.Working software is the primary measure of progress.Agile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.Continuous attention to technical excellence and good design enhances agility.Simplicity – the art of maximizing the amount of work not done – is essential.The best architectures, requirements, and designs emerge from self-organizing teams.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

It becomes clear that Agile is not a specific methodology, process, or framework but more of a mindset; a set of principles and ideals to guide us through the software development process.

This is a rather important concept to keep in mind: throughout my career, I've heard managers, directors, and developers boasting about being Agile because they have daily stand-up meetings, practice pair-programming, or use a Kanban board (more on these in Chapter 7, The Sprint Journey). All these are perfectly good tools to support an Agile development lifecycle, but their use alone does not make us Agile any more than wearing a cape and my underwear outside my pants makes me a superhero. To truly be Agile, you have to think and act in an Agile manner, that is in a manner consistent with the Agile Manifesto. One of the most popular ways of being Agile is by applying Scrum in your organization or team.

With this in mind, let's take a closer look at the Scrum framework.

What is Scrum?

In the previous section, we mentioned that in the late 1990s several visionaries were experimenting with flexible and adaptive ways to develop software. Two of these visionaries were Ken Schwaber and Jeff Sutherland. They came up with an Agile framework called Scrum, which was based on using the scientific method of empiricism, rather than strictly following a pre-defined plan. Scrum embraces Agile, not only because it was created by two of the people involved in the creation of the Agile Manifesto, but also because the Scrum values are actively derived from Agile principles (see Scrum Values meet Agile Principles in the Further reading section). In fact, most organizations that have adopted Agile methods use Scrum (see The State of Agile in the Further reading section).

It is important to emphasize that Scrum is a process framework, not a process by itself. It introduces a number of rules, milestones, and checkpoints that must be adhered to, regardless of the underlying development process. The Scrum framework can be used to contain a varied number of popular development methodologies, processes, or techniques, as per the organization's working practices. Scrum doesn't tell us how to perform our work, it just sets up a container within which to perform it. We can use whichever development methods and design or release processes we like, within Scrum. As long as these abide by the Agile and Scrum principles, it is absolutely fine to do so.

Scrum encourages the adoption of values such as respect for people, openness, and commitment in order to help us to cope with uncertainty and solving complex problems. It promotes the creation of self-organizing and cross-functional teams that are able to deliver working software independently and in spite of ever-changing external requirements and circumstances.

The Scrum framework consists of three components:

The Scrum Team: A self-organizing, cross-functional set of people who will deliver the working software.Scrum Events: A number of time-boxed events that help create regularity, provide feedback, foster self-adjustment, and promote an iterative and incremental lifecycle.Scrum Artifacts: Items that represent work or added value and that provide transparency for the team's work progress and achievements. Artifacts are also the cornerstone of inspection and adaptation.

The Scrum Team attends Scrum Events and creates Scrum Artifacts as well as working software. Events are attended at predetermined intervals and may trigger the generation or modification of artifacts. Artifacts may be inspected by the team but also by external inspectors. The following diagram illustrates these interactions:

Figure 1.1 – The Scrum framework components

The usefulness of Scrum lies in its three main components (Teams, Events, and Artifacts) and their interactions. We'll be discussing these components and interactions in detail in Chapters 3, The Scrum Team, Chapter 4, Scrum Events,and Chapter 5, Scrum Artifacts.

For now, let's take a look at one of the ways Scrum makes us work more efficiently and productively with the adoption of an iterative and incremental development lifecycle.

The value of an iterative and incremental approach

One of the greatest benefits of using Scrum is that it prescribes an iterative and incremental approach to software development. This is by far the most effective and efficient approach for creating software in today's world and in the next sections, we'll explain exactly why that is the case. Let's begin by remembering how we used to develop software…

The waterfall legacy

When I first started programming, we used to build our systems in distinct, single stages: first analysis, then design, then coding, and so on. Each stage would cover everything we would need to consider in order to deliver the whole system, down to the finest detail. Once the stage was complete, we would move on to the next stage of the development lifecycle and never re-visit the previous, completed stage. This is now known as the waterfall approach because each stage was like a distinct level of a waterfall, one following the other in sequential, non-repeatable fashion, as illustrated in the following figure:

Figure 1.2 – Waterfall development

As we soon came to discover, there were some serious drawbacks to this approach:

First, it took a long time to actually deliver software to our users. Since we had to consider every possible requirement, and design and document every possible functionality before we could start coding, it would take months or often years to progress from system inception to system deployment. By that time, a competitor would have beaten us to the punch by delivering their system first or the business need for our system would have simply passed, overtaken by circumstances and changes in the market. Secondly, since we were moving sequentially from stage to stage, any design flaws or false assumptions that were discovered after deployment could not be fixed without a major re-haul of our system. This took a lot of time and effort.Finally, if requirements were changed by the customer once we were past the design stage, we would have to start pretty much from scratch again.

In short, the waterfall approach was inflexible, risky, and time-consuming. It worked well for projects with rigid, unchanging requirements that were not affected by market conditions and weren't time-critical. However, as software applications started to become more prevalent in our lives and the market expanded and diversified, such projects started becoming rarer. Gone were the days in which consumers were happy to sit and wait for the next version of their spreadsheet application to come out from one of the two companies that produced them, or to wait for their email provider to fix a bug in their email system due to there being no real alternative.

Today, customers have plenty of choices and they value the speedy delivery of working software over dependence on monopolistic software providers. For software providers nowadays, time-to-market is an essential factor in their strategy and waterfall development is just too risky and rigid to follow. Luckily, the people who came up with Agile methodologies saw this at an early stage and almost all of the Agile methodologies that were developed, especially Scrum, follow what is known as an iterative and incremental development approach. Let's find out what that means.

Iterative and incremental software development

Iterative development means developing software in small chunks repeatedly, instead of waiting for everything to be finished and delivering a large chunk at the end. It entails breaking down the requirements that need to be implemented and implementing a few at a time. So instead of having a large, big-bang software delivery at the end of the project, we have many smaller deliveries at regular intervals. These delivery intervals are known as Iterations. In Scrum, we call an iteration a sprint.

Incremental development means that each iteration builds upon software delivered by previous iterations. So, if we implement Feature A in our first iteration (let's call this version 1 of our system), then in version 2 our users will expect to see Feature A and another feature too. Sometimes, we may have to deliver Feature A again, but this time working better or faster or having fixed a bug in it. The point is, each iteration should offer something more than the previous one. This chunk of software and functionality that each iteration adds to the system is called an Increment. In Scrum, an increment is not randomly produced but is intended to achieve a specific goal, to deliver the desired functionality or to fix a specific problem. This goal is decided at the beginning of the Sprint and is known as a sprint goal.

The following figure shows the characteristics of an iterative and incremental development approach:

Figure 1.3 – Iterative and incremental development

As shown, in an incremental and iterative development cycle, there is no separation between the development stages. So, within the same iteration, our team may be designing some feature, while coding some other feature, while testing a third one, all at the same time. This approach to development gives the developers the chance to correct any mistakes, fix any issues, and inspect and adapt to changing requirements at an early stage, which means less time and effort and less risk of failure or late delivery.

In an incremental and iterative cycle, we deliver working software at the end of each sprint. So, as illustrated, for Sprint 1 we deliver a crude version of our product that doesn't do much but outline what we try to build, with some basic functionality. At the end of the sprint, we showcase our software to the stakeholders and receive feedback. At the same time, we come together as the Scrum Team to inspect and review what we did well in the sprint and what we could improve. This gives us valuable information on how to improve the product in the next sprint, but also on how to improve our working practices.

In Sprint 2, we apply the lessons learned from Sprint 1 and deliver a much more functional version of the product with more and better features. Once again, at the end of the sprint, we receive feedback, inspect, and adapt in order to improve both our product and our workflow.

In the final sprint, we deliver the whole product, fully functional. By incorporating the feedback we received and the lessons we learned in the previous sprints, we understand the customer requirements much better and have improved our productivity and teamwork. In fact, inspection and adaptation are key pillars of Scrum (more about these in Chapter 2, Scrum Theory and Principles