Authors: Chris Sims, Hillary Johnson
Scrum: a Breathtakingly Brief and Agile Introduction Chris Sims, Hillary Johnson 2012
From the IT sphere to unpredictable projects (Scrum)
Authors: Chris Sims, Hillary Johnson
Scrum: The project management approach called Scrum was first mentioned in a 1986 Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka. The Japanese noted that projects with small multidisciplinary teams tend to achieve better results. They attributed it to the “rugby approach”, using the sports term Scrum (pushing, scrambling around the ball in play to keep it on the field). The Scrum methodology was clearly formulated and documented by American software engineers Ken Schwaber and Jeff Sutherland.
Scrum has gained its most popular in the technology sector, where small tight-knit teams create complex software. But it, according to the authors of this book, is easy to adapt to other industries. For example, Scrum tools can be used to improve a mousetrap, manage marketing for a dog food company, or collaborate on a book, as Chris Sims and Hillary Johnson did. They wrote a 54-page Scrum manual based on their 184-page bestseller The Elements of Scrum, published a year earlier and now used as a teaching aid in US universities.
“This tiny book — just the facts, ma’am — is an introduction to some of the drivers of Scrum: Roles, Artifacts, and Sprint Activities,” is how the authors described their latest collaborative writing effort to date.
Working in sprints allows Scrum teams to get more feedback—from team members, business customers, and users (customers)—and learn faster with it. What the team learns from one sprint helps plan for the next sprint. In Scrum, this is called “check and adapt” (one of Scrum’s mantras), but you can call it “continuous improvement,” as the authors suggest since the Scrum team is constantly focused on product and process improvement.
For Scrum to work, the following must be observed:
• verification and adaptation;
With the help of Scrum, many influential organizations in the world, including even the FBI, have reduced costs, and increased the speed and quality of teamwork. If a large state structure has been able to radically improve its method of operation, so can you.
Values, Agile Principles, and Scrum Elements
To better understand the essence of Scrum, Chris Sims and Hillary Johnson recommend reading the full text of the Agile Manifesto, signed in 2001 in the United States by representatives of various agile methodologies. This document contains 4 values and 12 principles (available on agilemanifesto.org in 68 languages).
1. People and interaction are more important than processes and tools.
2. A working product is more important than comprehensive documentation.
3. Cooperation with the customer is more important than agreeing on the terms of the contract.
4. Readiness for change is more important than following the original plan.
1. The highest priority is customer satisfaction through regular and early delivery of valuable software.
2. Changes in requirements are welcome even in the later stages of development. Agile processes allow you to use change to provide the customer
with a competitive advantage.
3. A working product should be released as often as possible, with a frequency of a couple of weeks to a couple of months.
4. Developers and business representatives must work together daily throughout the project.
5. Motivated professionals should work on the project. To get the job done, create the conditions, provide support, and trust employees completely.
6. Direct communication is the most practical and effective way to exchange information both with the team itself and within the team.
7. A working product is the main indicator of progress.
8. Investors, developers, and users must be able to maintain a constant pace indefinitely. Agile helps to establish such a sustainable development process.
9. Constant attention to technical excellence and design quality increases the flexibility of the project.
10. Simplicity – the art of minimizing unnecessary work – is essential.
11. The best requirements, architectural and technical solutions come from self-organizing teams.
12. The team should systematically analyze how they can improve performance and adjust their work style accordingly.
Scrum recognizes only three distinct roles:
• product owner;
• scrum master (scrum master);
• team member.
A Scrum Team consists of one Product Owner, one Scrum Master, and several members of the Product Development Team. The product owner and the scrum master complement each other: the first contributes to the improvement of the product, the second – to the process. Team members focus on results. As a general rule, the team should have from five to nine people. A smaller number of people may lack a variety of skills, and a larger number may have problems with productivity due to excessive spending on social communications.
Responsible for the fastest return on investment of business customers in team salaries, office rent, computers, software, etc. It increases ROI or, in simple terms, maximizes profits using the following methods:
• Guides the team towards the most valuable work (rather than the least valuable work) by prioritizing the product backlog. No one but him has the right to give the product development team any tasks or change the order of their execution.
• Makes sure team members fully understand the requirements. Otherwise, they will waste time creating unnecessary things.
Most often, the product owner adds requirements to the product backlog in the form of user stories. For example, “As a <role>, I want to <feature> to <achieve something>” or “As a <type of user>, I want to <do something> to <add value>.” This form is clear to everyone – developers, customers, customers.
For a user of an online bookstore and his employee, user stories may look like this: “As a consumer, I want to search for books by genre in order to quickly find those that I will surely like”, “As a representative of a customer — an online store — I want to track customer purchases to know what books to offer them.”Scrum
In addition, the product owner for each user story formulates acceptance criteria (acceptance criteria) – sufficient conditions for satisfying users. In everyday terms, in a pizzeria, the acceptance criteria would be a pizza of the size and composition of the ingredients ordered by the customer.
Each completed user story should gradually increase the value of the product. In this case, one also speaks of its new growth.
Product Owner Features:
• holds the vision of the product for several sprints;
• represents the interests of business customers and clients (end users);
• prioritizes the product backlog by ordering the most important items (user stories) first;
• creates acceptance criteria for stories;
• Available to answer questions from team members.
Manages the process according to the rules of Scrum (he either already has experience in successfully applying Scrum, or has received special training for this). If the Scrum team has not yet been formed, he selects suitable specialists. Later, he helps the product owner-run “science” events. In particular, he makes sure that the stand-up takes place standing, not sitting, does not last more than 15 minutes, and only the scrum team participates in it (without interested persons, who in this case can only observe without interfering).
If the result of the team’s work is a product, then the result of the Scrum Master’s work is a highly effective team. He, as a coach, directs her to higher levels of cohesion, self-organization, and productivity. As a Scrum Expert, he helps the team learn, and apply Scrum and related agile practices. When there are obstacles (which become known during the same stand-ups) that prevent team members from doing their work, he helps to eliminate them. At the same time, despite the differences in knowledge and responsibilities, he is on a par with the team members, and not their boss.
Scrum Master Functions:
• trainer; • Scrum expert and consultant; • Eliminator of organizational barriers; • project curator.
Member of the team
Members of high-performing product teams work very closely with each other and self-organize. They decide for themselves what tools and methods they will use and who will work on what tasks.
In theory, performers are the ultimate authority on how best to do their job. Therefore, team members themselves predict the timing of tasks.
Ideally, in a team of specialists, everyone should have their own unique skills. The mission of each team member is to help release a potentially finished product in each sprint. The best ways to do this are to contribute to work in your area of specialization or, when necessary, to work outside of your area of expertise to best take user stories from “in progress” to “done.” That is, team members, focus not on the process of work, but on the results. If your employees are different, they should change their way of thinking.
Team member functions:
• is responsible for completing user stories to gradually increase the value of the product;
• self-organizes to do all the necessary work;
• predicts the timing of tasks and owns them;
• Knows how to get the job done and avoids thinking, “That’s not my job.”
Artifacts are tools that Scrum practitioners use to achieve transparency in the process. Chris Sims and Hillary Johnson refer to them as:
• product backlog;
• sprint backlog;
• task burning chart (burn chart);
• task board;
• readiness criteria (definition of done).
This is a wish list that includes everything that could be useful for building the product: new features, bug fixes, documentation changes, and so on. Developers refer to these list components as “backlog items” or “user stories.” The last term is reminiscent of the fact that they create products to meet the needs of users.
The list of user stories is ordered so that the most important story (the one the team needs to do first) is at the top of the list. Right below it is a story that the team needs to do later, etc. Stories at the top of the backlog should be small and well understood by the whole team, and at the bottom, they can be larger and less clear, as time will pass before the team will work on it.
Each user story in the product backlog should contain the following information:
• for what users it will be useful (for whom it is);
• a brief description of the desired functionality (what needs to be created);
• the reason why this story is valuable (why we should do it);
• an estimate of how long it will take to work on the story;
• acceptance criteria that will help you know when the story will be implemented.
Sprint team to-do list. Unlike the product backlog, it has a finite lifespan equal to the length of the current sprint. The sprint backlog includes the stories that the team has committed to completing in that sprint and the tasks associated with them. Stories are the future results of the sprint that business customers and product users (customers) are waiting for. You can think of them as units of product value, and tasks as units of work. To complete the stories, you need to complete tasks. Each story usually requires many tasks. At the same time, a team works on the story, and one person works on the task.
Task Burndown Chart
Shows how much work the team has done in a given period of time and what remains to be done. The horizontal x-axis is the time measured in sprints, and the vertical y-axis is the number of tasks. The remaining work line is expected to decrease over time as the team completes it. But sometimes the amount of work changes suddenly when new tasks are added or old ones are removed. These events are displayed as a vertical line: it moves up when tasks are added, or down when some part of the work is removed from the plan.
When team tasks are visible to everyone in the room, there is no need to worry about some of them being forgotten. The simplest task board consists of three columns: what is to be done (to do), done (doing) and done (done). Tasks move through all columns, providing visibility into which tasks have already been completed, which are in progress, and which have not yet started. This helps the team see their current situation and adapt as needed, as well as see the team’s progress to the stakeholders – project initiators (business customers) and users (customers).
Readiness criteria is a list of actions agreed by the team with the product owner to complete the user story or the conditions necessary to satisfy customers.
For example, in a pizzeria, this means that the pizza is baked, sliced, and served.Scrum
Combining acceptance criteria (comparable to content, “pie filling”) with completion criteria (shape) results in the right product, made in the right way. When a team finishes a user story, there can be confusion as to what exactly the word “done” means.
A programmer can consider work done when the code is written, a tester when the growth of the product is tested, an operator when it is uploaded to the server, and a businessman when it is ready for use and can be sold to customers. Because of the difference in understanding, trouble can arise if the customer suddenly asks why the team is still working on a story that, as the programmer said, was completed two weeks ago.Scrum
To avoid confusion, development teams create their own user story readiness criteria. They decide together what tasks need to be done to complete the story and make a checklist.
Checklist items might include: writing new code, unit testing, regression testing, writing documentation, signing a document by the product owner, etc.Scrum
The authors of the book recommend printing out the readiness criteria and hanging them next to the task board. When the team members decide that the story is “finished”, they will come together and confirm that each item on the list is ready. Only then will the Scrum team declare the story complete.
The basic rhythm of Scrum is the sprint (also known as the cycle or iteration) – a fixed period of time during which the team “bites off” small pieces of the project before “swallowing” the rest. The shorter the sprint, the more often:
• the team demonstrates the potential growth of the product;
• receives feedback important for testing and adaptation;
• Benefits the business by giving customers the freedom to choose when and what to release.
In the latter case, two separate questions arise:
1) For the team – is the product ready for delivery? That is, is the quality of the product high enough for a business to use it? Are all current stories completed?
2) For business – does it make sense to supply what is currently available? Is there enough added value to bring the current product to market?
The sprint includes five meetings (also called meetings, meetings, events, events, or ceremonies):
1) sprint planning;
2) daily scrum (daily scrum), aka standup (stand up);
3) storytime, also known as grooming;
4) sprint review;
5) retrospective (retrospective).
If you view meetings as a form of repetitive stress trauma, the authors recommend calling them ceremonies, as many Scrum proponents do.
Most of the original sources of Scrum suggested a month-long sprint – at that time such a cycle seemed very short. At the time of writing, Scrum teams were already working in two-week sprints, and many were starting in weekly sprints. Therefore, the table below shows the duration of meetings for a weekly sprint team – this is a starting point that you should focus on.
Sprint planning marks the beginning of the sprint. This meeting usually consists of two parts. The purpose of the first is to assign user stories to the team, and the purpose of the second is to distribute tasks.
Part one: What are we going to do? In the first part of the meeting, the product owner, in order of priority, one by one, presents the user stories that he would like the team to complete during the upcoming sprint. The team discusses the acceptance criteria for the first story with the product owner to make sure they understand them correctly and decide if they can complete it before the end of the sprint. This process is repeated with each story until the team feels that they can no longer complete any work in the allotted time. Note the separation of concerns: the product owner decides which stories are considered, but the team members who do the actual work decide how many stories they can take on.
Second part: How do we do it? In the second part of the sprint planning meeting, the team rolls up their sleeves and starts breaking down selected stories into tasks.
Example Tasks: Obtain additional information from users, design a new screen, add new columns to the database, black-box test a new feature, write product help text, run scripts.Scrum
During this half of the meeting, the product owner answers questions, and team members can adjust the list of stories if they feel they’ve taken on too many or too few stories.
The result of the sprint planning meeting is the sprint backlog, a list of all committed stories with their associated tasks.
Before the end of the sprint, the Product Owner is responsible for giving advice on the product as needed, agreeing on the scope of the stories, and not asking for more stories unless the team asks for more. For a development week, the authors recommend one to two hours of sprint planning.
Daily Scrum, sometimes called a stand-up rally or simply stand-up for short:
1) Regular. Most teams prefer to have this meeting early in the day. You can choose another time according to your team’s preferences.
2) Brief. The point is to discourage moralizing and discourses that “lead to hell.” Daily Scrum should always be no longer than 15 minutes.
3) Purposeful. Each participant quickly shares a topic:
• what tasks have been completed since the last daily scrum; • what tasks are expected to be completed by the next daily scrum; • what obstacles hinder it.
The purpose of this meeting is to test and adapt the work of the team in order to complete the stories successfully. Verification takes place at the meeting, and adaptation can be after. This means that the team does not need to solve problems in the meeting, it is enough just to identify them and decide who will take care of them.
In this meeting, the team estimates the scope of future stories in the product backlog (i.e., how long it will take to complete a particular story) and breaks down large stories into smaller ones. Because each story in the product backlog must include a list of acceptance criteria, the team also checks with the product owner in this meeting to know when the stories should be implemented as intended. Please note that this is not about the stories of the current sprint – they are now in the sprint backlog.
The team needs to break down large stories into smaller stories to move them up the product backlog list. Small stories are easier to understand and easier to complete in a short period of time. Unlike the smaller stories, the larger ones lower in the backlog are less clearly defined.
While the product owner can do most of this work on their own, storytime or product backlog grooming is their chance to get help from the whole team. At the time of this writing, storytime is not an official Scrum meeting. Chris Sims and Hillary Johnson suggest that this will happen in the future, as all the high-performing Scrum teams they know to clean up the product backlog during this meeting. The authors recommend doing this every week for an hour, regardless of the length of your sprint.
The sprint review is at its public end: all interested parties are invited to this meeting. It’s a chance for the team to showcase their accomplishments – completed stories as well as unfinished ones (which they promised to complete by the end of the sprint but didn’t complete), and for stakeholders to see the product gradually improve. During the sprint review, the product owner and team members receive feedback from customers and users to help validate and adapt the product.
No decisions are made at this meeting. Decisions on whether the stories are finished should be made prior to this meeting and what to do during the next sprint at the sprint planning event.
The authors recommend reviewing the sprint for 30-60 minutes per development week. That is, if you have a two-week sprint, the meeting could take one to two hours. Once you’ve done this a few times, you’ll know how long it takes for your team to review and adapt.
During a retrospective at the very end of each sprint, team members review what they learned during the sprint and how it can be applied. Unlike traditional debriefing, the purpose of a retrospective is not to generate a long list of things that went well and badly but to identify one or two strategic changes that should be made in the next sprint to improve the process.
Holding a retrospective is especially important after an abnormal (crash) ending of a sprint as it helps the team learn from experience. After all, sometimes something happens that invalidates the sprint – the business is sold, the customer is outpaced by a competitor, or a technology entered the market that turned out to be better than the one that the Scrum team was working on.
“Despite the name (abnormal sprint termination), neither Arnold Schwarzenegger nor James Cameron should interfere. If the product owner is forced to end the sprint early, the team should discard any changes made during the sprint to avoid problems with under-work.”Scrum
Fortunately, this happens quite rarely and is generally atypical. Therefore, for each week of development, the authors recommend one to two hours of retrospective.
Ready, attention, sprint!
Top 10 Thoughts
1. Understanding the essence of Scrum and the effective use of its tools are facilitated by the Agile values: people and interaction, a working product, cooperation with the customer, and readiness for change are important.
2. Scrum is all about the continuous product and process improvement.
3. Scrum provides many opportunities to receive feedback from the business customer, team, and market – and improve with its help. Experience is the best teacher: by completing work in one sprint, you learn something that helps you plan for the next one.
4. The main elements of Scrum are roles, artifacts, and activities.
5. In the Scrum team, the roles are distributed as follows: product owner, scrum master, and team member. The fourth role is not given, as well as reducing them to two.
6. Scrum artifacts make team efforts transparent. Chris Sims and Hillary Johnson refer to the product backlog, sprint backlog, burndown chart, task board, and readiness criteria as artifacts.
7. The main rhythm of scrum is the sprint period, lasting from one week to a month. The shorter the sprint, the more often the team provides a potential increase in the product and the customer has more choice when and what to deliver to users or customers.
8. Sprint activities include sprint planning, daily scrum, storytime, sprint review, and retrospective.
9. The purpose of the retrospective is to identify one or two strategic changes that need to be made in the next sprint to improve the process. This is especially important in the event of a sprint crash.
10. The authors of the book recommend that teams work in one-week sprints, with one to two hours for sprint planning, no more than 15 minutes for daily stand-ups, one hour for storytime, and 30 to 60 minutes for sprint review, and one to two hours for a retrospective.