Scrum Overview
Mục lục bài viết
Understand Scrum in 60 minutes.
Watch The Scrum Foundations
Website
First Name
Email Address
We hate spam and promise to keep your email address safe. Unsubscribe at any time. Privacy Policy
What Is Scrum? What Is the Definition of Scrum?
What is Scrum? Scrum is an agile way to manage work. Ever few weeks (typically two to four), teams deliver a fully functional chunk of work (an increment). Teams and the business use the feedback from each delivery to determine what to build next, or how to adapt what they’ve already built.
Put very simply, Scrum works through a series of events that happen over a defined period of time: that time period is called a sprint. Sprints are short timeboxes during which the team turns ideas into working product. The events then repeat every sprint.
The Scrum Framework
When tallking about the Scrum framework, one of the first things to understand is that we purposefully define a Scrum framework rather than a Scrum methodology, Scrum model, or Scrum development process. A methodology or process will specify essentially everything about how work should be performed when using that approach.
An agile framework is different. Unlike a process or methodology, a framework is purposefully incomplete.
For example, Jeff Sutherland’s and Ken Schwaber’s Scrum Guide says that a team needs to produce high quality work, but doesn’t say how the team is to achieve that.
Teams are the heart of any agile project management framework. Instead of providing complete, detailed descriptions of how everything is to be done on a project, much of it is left up to the team. This is because the team will know best how to solve the problem they are presented.
This is also why the activities of a sprint are described in terms of the desired outcome instead of a set of entry criteria, task definitions, validation criteria, exit criteria (ETVX) and so on, as would be provided in most methodologies.
The definition of Scrum is simple and small. Remember, though, that the parts that are there have been shown to work over and over again. Be very careful, therefore, about deciding to remove something, especially before you have sufficient experience to make very educated guesses about how removing something would affect the other parts.
Scrum Team Roles
Scrum relies on a self-organizing, cross-functional team of developers. By that, I do not just mean software developers—anyone involved in creating work for the sprint is called a developer.
The team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole.
A team is cross-functional, meaning everyone is needed to take a feature from idea to implementation.
A typical team has between five and nine people, but projects can easily scale into hundreds of people divided among many teams. Individuals may join the team with various job titles; those titles are insignificant. Each person contributes in whatever way they can to complete the work of each sprint.
This does not mean that a tester will be expected to re-architect the system; individuals will spend most (and sometimes all) of their time working in whatever discipline they worked beefore they joined the team. But individuals are expected to work beyond their preferred disciplines whenever doing so would be for the good of the team. In this way, teams develop a deep form of camaraderie and a feeling that “we’re all in this together.”
Development teams are supported by two specific roles. The first is a Scrum Master, who can be thought of as a coach for the team. Scrum Masters help team members use the process to perform at their highest level, and remove impediments to progress.
A good ScrumMaster also shelters the team from outside distractions, allowing team members to focus maniacally during the sprint on the goal they have selected.
A ScrumMaster differs from a traditional project manager in many ways, including that this role does not provide day-to-day direction to the team and does not assign tasks to individuals.
While the ScrumMaster focuses on helping the team be the best that it can be, the product owner works to direct the team to the right goal.
The product owner is the project’s key stakeholder and represents users, customers and others in the process. Because of this, many product owners come from product management or marketing. Product owners guide the team toward building the right product.
Product owners do this by creating a compelling vision of the product, and then conveying that vision to the team through an artifact called the product backlog.
The product owner is responsible for prioritizing the backlog, to ensure it’s up to date as more is learned about the system being built and its users.
One way to think of the interlocking nature of these three roles in this agile methodology is as a racecar.
The team of developers is the car itself, ready to speed along in whatever direction it is pointed. The product owner is the driver, making sure that the car is always going in the right direction. And the ScrumMaster is the chief mechanic, keeping the car well tuned and performing at its best.
Scrum Activities
Each sprint begins with a sprint planning meeting, where the product owner presents the top items on the product backlog to the team, and team members figure out how much work they can commit to during the coming sprint.
During each sprint, the team takes a small set of features from idea to fully implemented and tested functionality. At the end, these features are done and could potentially be released to customers.
On each day of the sprint, all team members attend a daily scrum meeting. Daily scrums are a way for team members to synchronize their work and collaborate to move that work to done. The daily meetings last no more than 15 minutes and are intended to give the team a time to share what they worked on the prior day, will work on that day, and identify any impediments to progress.
At the end of a sprint, the team conducts a sprint review during which the team demonstrates the new functionality to the product owner or any other stakeholder who wishes to provide feedback that could influence the next sprint. It’s critical that the sprint review remains informal and doesn’t become its own task, distracting from the work itself. On some teams, for example, PowerPoint slides are not allowed. Other teams ask attendees to take each feature for a hands-on test drive .
This feedback loop may result in changes to the freshly delivered functionality, but it may just as likely result in revising or adding items to the work planned for the future.
Another inspect-and-adapt activity is the sprint retrospective at the end of each sprint. The whole team participates in this meeting. The meeting is an opportunity to reflect on the sprint that has ended and to identify what changes or improvements the team may wish to make to the process itself.
Both of these end-of-sprint activities are consistent with the agile value of continuously improving.
Scrum Artifacts & Tools
Scrum has several artifacts and tools. The primary artifact is, of course, the product itself.
The product backlog is another tool. The product backlog is the list of the functionality that remains to be added to the product. The product owner prioritizes the backlog so the team always works on the most valuable features first.
The most popular and successful way to create a product backlog is to populate it with user stories, which are short descriptions of functionality described from the perspective of a user or customer.
On the first day of a sprint and during the planning meeting, team members create the sprint backlog. The sprint backlog can be thought of as the team’s to-do list for the sprint. The sprint backlog is the list of tasks the team needs to perform in order to deliver the functionality it committed to deliver during the sprint.
Unlike the sprint backlog, the product backlog is a list of features to be built over many sprints.
During the sprint, most teams use a task board (virtual or physical) to visually represent the flow of sprint backlog work as it moves from To Do, to Doing, to Done.
Though not required, teams often use and create sprint burndown charts and release burndown charts. Burndown charts show the amount of work remaining either in a sprint or a release, and are an effective tool to determine whether a sprint or release is on schedule to have all planned work finished by the desired date
Visual Introduction to Scrum
To undestand how all of the pieces of Scrum work together, let’s look at how they essential elements of Scrum are depicted graphically.
On the left, we see the product backlog, which has been prioritized by the product owner and contains everything desired in the product that’s known at the time. The product backlog is depicted by a tall stack of large blue cubes.
The two-to-four week sprints are shown by the larger green circle.
At the start of each sprint, the team selects some amount of work from the product backlog and commits to completing that work during the sprint. Part of figuring out how much they can commit to is creating the sprint backlog, which is the list of tasks (and an estimate of how long each will take) needed to deliver the selected set of product backlog items to be completed in the sprint.
The sprint backlog is shown just to the left of the green circle, and is represented by a short stack of small blue cubes.
At the end of each sprint, the team produces a potentially shippable product increment — i.e. working, high-quality software. That increment is shown to the right of the sprint (an an output) and represented as a brown package.
Each day during the sprint, team members meet to discuss their progress and any impediments to completing the work for that sprint. This is known as the daily scrum, and is shown as the smaller green circle above the sprint.
FAQs
What Does Scrum Stand For?
Uniquely agile, the Scrum methodology does come with a funny name. People often ask “What does Scrum stand for? It isn’t an acronym and doesn’t stand for anything. The term comes from the rugby approach described by Hirotaka Takeuchi and Ikujiro Nonaka in their 1986 “The New New Product Development Game.”
Is Scrum a Methodology?
Is Scrum a methodology? No, Scrum is not a methodology. And it isn’t called a Scrum model. Models and methodologies give step-by-step guidance about exactlly how work should be performed.
Scrum is a framework. It provides a structure to work within and desired outcomes to achieve, but leaves teams room to decide how best to achieve those outcomes in their specific context.
Agile vs Scrum: What’s the Difference? Is Scrum Agile?
When it comes to Scrum vs agile or Scrum in agile contexts, it helps to think of agile as an umbrella. Under the agile umbrella are many frameworks: XP, Kanban, Scrum, and more.
So, Scrum is agile. But just because a team is agile, doesn’t necessarily mean they are using Scrum project management techniques or a framework that fits the Scrum definition. They could well be using another agile technique.
I started doing agile software development with Scrum more than 20 years ago, and I can tell you that it works for most complex projects. Scrum software development has evolved over the years to encompass all types of products, well beyond software.
Introduction to Scrum Terms
An introduction to Scrum would not be complete without knowing the terms you’ll be using.
Scrum team: A typical team has between five and nine people, but projects can easily scale into the hundreds, or just be one-or two-person teams. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Teams develop a deep form of camaraderie and a feeling that “we’re all in this together.”
Product owner: The product owner is the project’s key stakeholder and represents users, customers and others in the process. The product owner is often someone from product management or marketing, a key stakeholder or a key user.
Scrum Master: The Scrum Master is responsible for making sure the team is as productive as possible. They do this by helping the team use the Scrum process, by removing impediments to progress, by protecting the team from outside, and so on.
Product backlog: The product backlog is a prioritized features list containing every desired feature or change to the product. Note: The term “backlog” can get confusing because it’s used for two different things. To clarify, the product backlog is a list of desired features for the product. The sprint backlog is a list of tasks to be completed in a sprint.
Sprint planning meeting: At the start of each sprint, a sprint planning meeting is held, during which the product owner presents the top items on the product backlog to the team. The team selects the work they can complete during the coming sprint. That work is then moved from the product backlog to a sprint backlog, which is the list of tasks needed to complete the product backlog items the team has committed to complete in the sprint.
Daily scrum: Each day during the sprint, a brief meeting called the daily scrum is conducted. This meeting helps set the context for each day’s work and helps the team stay on track. All team members are required to attend the daily scrum.
Sprint review meeting: At the end of each sprint, the team demonstrates the completed functionality at a sprint review meeting, during which, the team shows what they accomplished during the sprint.
Sprint retrospective: Also at the end of each sprint, the team conducts a sprint retrospective, which is a meeting during which the team reflects on how well their process is working for them and what changes they may wish to make for it to work even better.
