Scrum development methodology. Scrum: a revolutionary project management method

What is Scrum methodology? How to use it in development and beyond? Why is flexibility not always good?

My studies continue, three times a week I get acquainted with new knowledge in the field of developing and understanding digital products from the inside. For a marketer, this is a new world. You hear about some kind of Agile, you understand that it is connected with development and you can easily carry on the conversation in general terms. But as soon as it comes to the details, I floated.

The Scrum methodology is the most popular among all things agile in development and more. I became interested in understanding what it is and what the practical application of this tool is. I present a review for your consideration.

What is Scrum

Scrum is an agile development methodology or flexible management framework (i.e. structure) with an emphasis on process quality.

The essence of the methodology is that the creation of a product is divided into certain parts. A chunk of time or a sprint (usually 2 weeks) is allotted to complete such parts. At the end of each such sprint, it is necessary to demonstrate the completed piece. The picture above is just a general principle of the processes. Let's take a closer look.

How Scrum works

See below how Scrum actually works.

So far it looks like Chinese writing, so I suggest looking at the individual parts and disassembling each element of the structure. I highly recommend Boris Volfsan’s book “Agile Methodologies”; it formed the basis for this material (some of the pictures are from there).

Scrum Structure

Let's see what elements Scrum consists of.

Roles

• Product owner/manager. Sets a task, determines priorities for tasks, interacts with the customer.
• Scrum master is a person who is responsible for processes within the team, coordinates work, and monitors the internal atmosphere. Plans the sprint, organizes a scrum meeting, and participates in demonstrating results at the end of each sprint.

A Scrum meeting is a daily meeting where the progress of the sprint is discussed. What have you done, are there any problems, what are you planning to do? No more than 15 minutes per meeting. All team members must speak. The Scrum Master monitors everyone's timing and performance.

• Team – 7±2 people who implement the requirements of the product owner.

Artifacts

• Product backlog. List of requirements with priorities and labor costs.
• Sprint backlog. Part of the sprint backlog, that is, several tasks that can realistically fit into one sprint.
• Product increment. Finished part of the product for demonstration. In digital projects, this could be functionality. For example, a working registration form on the site that can be shown.

Processes

• Sprint planning. The team with the Scrum Master plans a work plan for the future sprint, that is, draws up a sprint backlog (list) of tasks.
• Sprint review. Demonstration of product increment after each sprint. The team shows the working functionality to the product owner (and the customer upon request), who in turn makes changes to the requirements if necessary.
• Retrospective. Review of the past sprint to improve processes. The team, Scrum Master and Product Owner discuss the past sprint, draw conclusions, and think about what could be improved.
• Scrum meeting. (see definition above in the “Roles” block)
• Sprint. As a rule, a two-week stage of time during which the team manages to develop functionality ready for demonstration.

Sorry to interrupt reading. Join my telegram channel. Fresh announcements of articles, development of digital products and growth hack, it’s all there. Waiting for you! Let's continue...

Scrum example

Imagine that you need to create a website/service for cleaning your summer cottages. You have a country house where the area is in complete disarray, and it’s not possible to spend your weekends cleaning, because you want to relax a little. Therefore, voila, Uberimoydvor service!

We believe that the service will be website based. The user registers, leaves a request and an operator calls him back, who clarifies the details and agrees on a time convenient for the client. We want to use Scrum to develop the website.

We select, for example, an important task or user story as part of creating a website: “Registration of a client/user”. And break it down into smaller parts. We create a product backlog.

The main user story is broken down into small tasks. Next, together with the team, priorities are set and tasks are divided into sprints. Don’t forget about the basic rule: after the sprint we must have ready-made functionality for demonstration.

In practice, there are much more user stories (such as “User Registration”). A service/product may include many such stories, so prioritization is built from top to bottom, from left to right. In the upper left part are the most important user stories (Activities) and the most important tasks.

To display the task backlog, regular sticky notes and a board (sometimes even a wall) are used. Here's what it might look like.

It is clear that it is simply impossible to manage such a “colossus” in real time, therefore, for ease of work, this entire wall is moved to a special software/program (Jira, Trello, Redmine and other project management trackers). There you can assign responsibility for tasks and executors, change task statuses, etc.

The wall also works well, because at the creation stage the whole team is passionate and feels they are contributing to the common cause. But after that you need to transfer it to a suitable tool.

Let's get back to cleaning the yard. So we chose sprints with tasks and started working. The team completes the amount of work every day, and the Scrum Master organizes 15-minute planning meetings (Scrum meetings), where he updates the status of sprint tasks and finds out difficulties in the work if they arise.

It is very important that the Scrum Master monitors the climate and relationships within the team; his task is to form and maintain a self-organizing, motivated team. To do this, it is necessary to resolve issues and misunderstandings between all participants. The Scrum Master is a coach who improves the team.

After a 2-week sprint, the Scrum Master and the team conduct a functional demonstration. In our example, we managed to create a registration form and are showing it to the product owner. He looks and makes adjustments if necessary. Once the work is accepted, we move on to the next sprint.

Retrospective: Sprint Analysis

A few days after the completion of the sprint, the product owner, scrum master and team should get together and conduct a retrospective (sprint review). This is a meeting of several hours (depending on the length of the sprint and the size of the team) where the difficulties that arose in the last sprint are sorted out.

Participants share their opinions and decide what can be improved in future sprints. Thus, there is a natural evolution of processes, since with each new iteration the previous experience is taken into account and analyzed.

How to prioritize

It's good that we use Scrum management, but how to prioritize a huge list of user stories? After all, a project can include a lot of such stories.

That's what a product owner is for. It is he who understands the needs of the audience, monitors the market and draws conclusions about what should be done in the backlog. The main task is to solve the client’s need and start better with the most important one.

At the same time, it is necessary to take into account the capabilities of the team. How many problems can she solve in a sprint? What kind of tasks are these? How to plan the overall progress of implementation? Evaluating inside the backlog will help.

Evaluating user stories inside the backlog

We have created a backlog, but how to evaluate user stories in terms of complexity? For this purpose, the standard method is used. This is a relative assessment that allows you to understand the team's potential and roughly estimate resources.

We take one user story from the backlog as a sample and assign it a value of one (story point). Next, we evaluate other user stories from the point of view of the chosen one.

For example, in our service there is a user story “User Registration”. We take it as a sample and give it a value of one point or one story point (as it is called in flexible methodologies). Each team member writes his own assessment for the rest of the user stories on the list, taking into account the task that was taken as a sample and gives it to the Scrum Master.

In the example above, “Photo gallery with satisfied customers” costs 0.5 story point, that is, in complexity it is 2 times less than our reference story “User registration”. Team members give all ratings anonymously; you can write and turn them over on stickers.

When everyone has given their ratings, the results open. The Scrum Master facilitates a discussion among the participants who have given the most extreme estimates. In the picture above, these are 2 and 8. They agree among themselves and the second round of voting starts.

All participants must come to a common opinion and the scores are equalized. As a result, we get a breakdown of all user stories based on relative scores.

Next, taking into account priorities, tasks are collected into sprints and work begins. Based on the results of completed sprints, it becomes clear how many story points the team can approximately complete. And in the process of analysis (retrospective) afterwards, points of growth may be found.

This gives us an internal meter or currency that the team receives per sprint. It can be used to measure the effectiveness of the team and predict future iterations.

Is it possible to use Scrum not only in development?

Yes and no. Before I began to understand what these 5 letters (Scrum) mean, I already used some of the principles in my work. Planning, using various tools and building your so-called “task sprint” has already happened.

But still this is not Scrum. Scrum is a methodology and system that allows you to be flexible and constantly improve processes within a team.

Tasks should be typical. Whatever one may say, development is an engineering practice, that is, a task can be brought to a certain standard. And this is much easier to do than, say, in the field of creativity, marketing or management.

Some practices from the methodology are quite applicable in other areas. Working with the team and analyzing the work done, yes. Forecasting tasks at a time stage, yes. Task management in convenient programs, too, yes.

When to use Scrum

Mainly in small projects and start-ups. It is possible in large ones, such as Mail.ru, but there should be a certain freedom of action and separate functional teams with their own product owner. Don't forget that Scrum is about flexibility and change. Teams should not be larger than 7±2 people, otherwise it will be impossible to effectively organize communications.

Nuances

If you decide to implement Scrum in your projects, then take into account the following nuances:

• No customer focus. Not all customers will be ready for certain Scrum standards.
• The risk response system is not taken into account. The team can set aside some additional time to complete tasks, but if there are significant deviations from the plan, the system will stop.
• Team and human qualities. Since the emphasis is on a self-organizing team, all participants must have a high level of responsibility and appropriate motivation. Creating such a team is a very difficult task.
• Scrum Master. The person responsible for the processes and motivation of the team must feel all the participants and connections within the group. This is a rare specialist who is also difficult to find on the market.

Let's finish

Despite the nuances and features of Scrum methods, I would like to note that it still remains the most popular among all flexible methodologies. Some of its parts can be applied in other areas of business, and the principles can form the basis of your own development strategy.

Scrum is one of the possible ways to implement flexible (Agile) development methodology. Unlike the waterfall model of the software life cycle, the distinctive feature of Scrum is iterativeness.

The development process is divided into separate stages, the result of each of which is a finished product. At the end of each stage (in Scrum terminology, a sprint), the finished product is delivered to the customer. Feedback from the customer allows you to identify potential problems or revise some aspects of the original plan. Thus, Scrum allows you to best follow the principles of Agile development.

Before we begin describing the life cycle of a Scrum project, it is worth talking about the main roles adopted in the Scrum methodology:

• Product Owner (Product owner) represents the interests of the end user.
• Scrum master monitors compliance with the principles of Scrum development, coordinates the process, conducts daily meetings (Scrum Meetings).
• Scrum team (Scrum team) participates in product development. The Scrum team includes programmers, testers, analysts and other specialists.

So, let's look at the main development steps specific to Scrum.

Step 1: Create a Product Backlog

The Product backlog is a list of requirements for the product being developed, ordered by importance. The items in this list are called User stories. Each story has a unique ID. Here is an example of user stories from the product backlog used while working on XB Staff Manager:

The description of each story must include a set of required fields necessary for further work on the project:

• Importance. The degree of importance of the task in the opinion of the product owner. Described by an arbitrary number.
• Initial estimate. Preliminary assessment of the scope of work. Measured in story points.
• How to demo. Description of how to demonstrate a completed task.

In addition to these required fields, additional fields can be added if necessary:

• Category (Track) serves to allow the product owner to select all items of a certain category and assign them low or high priority. An example of such a category would be “Control Panel”.
• Components consists of a list of product components that will be changed while working on the story. These components can be application modules, such as authentication or search.
• Requestor- a customer interested in implementing a certain functionality. This field is necessary if you need to keep the customer informed of the current state of affairs.
• ID in the defect tracking system (Bug tracking ID) contains links to detected defects related to a story with a specific ID.

Once the project backlog has been compiled, you can proceed to the next step - sprint planning.

Step 2: Sprint Planning and Creating the Sprint Backlog

At the planning stage, the duration of the sprint is determined. A short sprint allows you to release working versions of the product more often, and therefore receive feedback from the client more often and identify possible errors in a timely manner. On the other hand, long sprints allow you to devote more time to solving a problem. The optimal sprint length is chosen as a cross between these two decisions and is usually about 2 weeks. At this stage, interaction between the product owner and the Scrum team is important. The Product Owner determines the priority of a particular task, and the Scrum team's task is to determine the required effort.

During sprint planning, the team selects the highest priority user stories from the product backlog and decides how the assigned tasks will be solved. The stories selected for implementation during this sprint are: Sprint backlog. The number of stories included in the sprint backlog depends on their duration in story points assigned to each story at the preliminary assessment stage. This number is chosen so that each story is successfully implemented by the end of the sprint.

Step 3. Work on the sprint. Scrum meetings

Once the user stories relevant to the sprint have been identified, the process begins.

It is convenient to use index cards to visualize the development process. These can take the form of large cards with the name of a specific story and small sticky notes describing the individual tasks required to implement the story. After you start working on a specific task, its sticker moves from the “Planned” field to the “In Progress” area. Upon completion of work on the task, the sticker moves to the “Testing” field and then, if testing is successful, to the “Done” field. By ranking stories according to their importance, you can get an idea of ​​the current state of the project:

Software designed for this type of task can also be used. An example of such software is, for example, Atlassian JIRA.

An important distinguishing feature of Scrum is daily meetings (Scrum meetings), the purpose of which is to give the team complete and reliable information about what stage the development process is at. During the meeting, each member of the Scrum team reports what task they have completed, what task will be performed, and what difficulties they encountered while working.

The outcome of each meeting is also burndown diagram. The X axis shows the days of work on the sprint, and the Y axis shows the total number of story points for this sprint. After completing a task that required a certain number of story points to solve it, you can mark on the diagram the point at which the project is currently located. An example of such a diagram built in JIRA is given below:

It allows you to evaluate the pace of the team's work and decide whether to increase or decrease the number of stories in the next sprint. Daily meetings help increase the flexibility of the development process and provide insight into the necessary adjustments that need to be made during the design phase of subsequent sprints.

Step 4. Product testing and demonstration

Since each sprint ideally delivers a production-ready product, testing is an important part of Scrum. There are different ways to minimize costs at this stage: from reducing the number of stories in the sprint and, as a result, reducing the number of errors to including testers in the Scrum team.

The finale of each sprint is a demonstration of the finished product. The Scrum team writes a review in which it describes the sprint goals, the tasks set and how they were solved. The product owner, customers and users, based on reviews and demonstrations, decide what should be changed in the further development process.

Step 5. Retrospective. Planning the next sprint

Based on the feedback received about the product after the demonstration, a retrospective is conducted. Its main goal is to determine how the development process can be improved in the next sprint to avoid problems and work more efficiently. Once ways to improve the quality of work have been identified, the team can begin planning the next sprint.

Conclusion

The hallmarks of Scrum are flexibility and a focus on continuous development and change. This is largely achieved through continuous communication and interaction. During the Sprint Planning phase, the Product Owner communicates with the Scrum Team to determine what tasks the user stories can be broken down into and how they can be implemented. During daily meetings, Scrum team members discuss the implementation of each individual task and identify possible ways to solve problems that have arisen. At the end of the sprint, the finished product is presented to the customer, who can evaluate the current functionality and note what he would like to change. This distinctive feature of Scrum can be useful if, over time, the customer's vision of what the product should look like changes. Finally, all the information obtained from these stages is taken into account in all subsequent sprints, which helps optimize the development process in the best possible way.

The following two tabs change content below.

What is Scrum. The essence of the technique

Those involved in project management, or simply management, know well how difficult it is to organize well-coordinated teamwork. Because of lack of coherence, plans are constantly violated, schedules are behind schedule, the project budget is inflated, money and time slip through fingers, tasks of different departments are duplicated, people argue and do not help each other, although it would seem that their efforts are aimed at achieving the same goal. In addition, customers are often dissatisfied with the final version of the created product.

The Scrum methodology, developed by Jeff Sutherland and Ken Schwaber, is designed to solve all these problems. Scrum— This is the opposite of the classic step-by-step approach taken to project delivery. The Scrum methodology has been adopted by many companies, both from the technological industries where it comes from, as well as from traditional and even non-profit ones. The approach underlying the Scrum methodology can be applied to a variety of activities that require teamwork.

Important characteristics of Scrum are its flexibility and customer focus, since it assumes his (the client's) direct participation in the work process.

Scrum does not require implementation any expensive tools. The Scrum methodology can be briefly described as follows:

1. First you need to select« Product Owner» — a person with a vision for what you are going to create or achieve.

2. Then you need to collect"Team" , which will include people directly performing the work. They must have the skills and knowledge to help bring the product owner's vision to life.

3. You need to select a “Scrum Master” - someone who will monitor the progress of the project, facilitate short meetings and help the team remove obstacles to achieving the goal.

4. When starting work, you need to create the most complete list of all the requirements for the product or goal. The items on this list should be prioritized. The list is called"Product Backlog" . It can evolve and change throughout the life of the project.

5. Team members must evaluate each item using their own scoring system for the difficulty and cost that will be required to complete it.

6. Then the participants Scrum Master and the product owner must conduct the first scrum meeting , where they will plan the sprint— a certain time to complete part of the tasks. The duration of the sprint should not exceed one month. For each sprint, the team earns a certain number of points. The team should constantly strive to exceed the number of points accumulated for the previous sprint in the new sprint, that is, its goal— consistently exceed your own results— « increase productivity dynamics» .

7. In order for all participants to be aware of the state of affairs, you need to create scrum board with three columns:« Need to do, or backlog" ; "In progress"; " Made " . Participants put stickers with tasks on the board, which are moved one by one from the column as they work.“Backlog” into the “in progress” column and then into the “done” column.

8. Conducted daily scrum meeting . According to Jeff Sutherland« this is the pulse of the entire Scrum process» . Its essence is simple— Every day, on the go, fifteen minutes for everyone to answer three questions:« » , « » , « » .

9. At the end of the sprint, the team reviews it— holds a meeting at which participants talk about what has been done during the sprint.

10. After showing the results of the sprint, the participants hold a retrospective meeting where they discuss what the team did well, what could be done better, and what could be improved right now.

Disadvantages of the Traditional Project Management Approach

As the author of the book, Jeff Sutherland, notes, the traditional approach to project implementation in the form of a waterfall model, which involves step-by-step progress towards a goal, has many disadvantages. The whole process is very slow, unpredictable difficulties often arise and, moreover, it often happens that the contractor creates a product that does not satisfy the customer at all.

The waterfall model involves the use of Gantt charts— schedules that indicate the stages of work and the time for their completion. The progress of the project is mapped out in detail and every step of the work is reflected. It is assumed that each phase of the project sequentially moves into the next,— This is the cascade principle.

Why? As Jeff Sutherland notes, Henry Gantt invented such charts back in 1910. They became widespread in the First World War. However,« Anyone who has studied the history of this war knows that neither the training of manpower nor the system of organization were ever its strong points. I can't understand why the World War I conceptbecomes de factoanalytical design tool and is used even in the 21st century. We abandoned the principles of trench warfare, but somehow its „trench“ organizational ideas remain popular to this day» .

In modern conditions, this scheme is inappropriate and is similar to the model of the Politburo of the CPSU Central Committee, which"believed" reports that it received on the eve of the collapse of the Soviet Union and which had little to do with the real state of affairs.

Scrum philosophy

The Scrum methodology reflects the author’s passion for Japanese martial arts. According to him, in Japan« Scrum is not treated as a fad. The Japanese regard Scrum as an approach to solving problems, as a way of action, as a way of being — in general, as a way of life. When I teach people this technique, I often talk about my many years of experience in the Japanese martial art of Aikido. » .

What Aikido and Scrum have in common is that they can only be mastered in the process of work, when« your body, your mind and your spirit come together as one through constant practice and the pursuit of excellence. By practicing Aikido, we understand the concept of shuhari (Shu Ha Ri) — it is both a martial arts concept and an indicator of skill level » .

The essence of teamwork in Scrum

Scrum - This is, first of all, teamwork. The author identifies three characteristics of the best teams:

the never-ending search for excellence;

• autonomy - ability to self-organize;
• multifunctionality. The presence of different specialists and a culture of interaction and mutual assistance.

What size should the team be? Jeff Sutherland recommends small groups— about seven people. He cites data that if a group consists of more than nine people, then the speed of its work drops.

In addition, the author recalls “Brooks’ law”:

« If the project is not on time, adding more labor will delay it even further. » .

Chief of the team- this is the Scrum Master . His duty— keep meetings short and open, help the group move through obstacles that get in the way of work, lead the team along the path of continuous improvement« and regularly look for the answer to the question« How can we do even better what we already do well?» .

No multitasking

The author warns against multitasking— in fact, there is none, our brain cannot perform two actions at the same time, it simply switches between tasks, and the total time to complete each of them increases compared to if we performed them alternately. The Scrum methodology assumes that you need to perform all tasks one by one, and not« manage five projects simultaneously» .

« Using the traditional method of trying to do everything at once, the group will complete its three projects before the end of July. If the team approaches it with an agile strategy like Scrum and works on each project one at a time, minimizing the time and effort involved in context switching, it could be done by early May. » .

The essence of the work is flow

Scrum helps you get to"flow" - a state of highest concentration when you do what you need to do without expending effort on it, without forcing yourself or pushing yourself. The author believes that the main thing for successful work— achieve and manage this state.« In your work you need to achieve the main thing— effortless flow control. In martial arts or meditation practices, we achieve a sense of unity in movement that does not require effort,— it is energy flowing through us unhindered. When you watch great dancers or singers, you feel how they submit to this energy. We must strive to achieve such a state in our work.» .

How to achieve it? Behind the state of flow is internal discipline,

« No movement should be wasted » .

Scrum and happiness

People want to be happy. But Jeff Sutherland is sure that happiness— This is not an inactive vegetation, but a bright, rich and active life. Scrum contributes to a happy life because it helps you work and act productively.

At the end of each sprint, participants hold a retrospective meeting where they talk about their work and move the considered tasks into a column" Made " , and then discuss what is good and what can be improved. They find the main obstacle and figure out how to fix it in the next sprint. This is the solution to the problem of continuous improvement.

Elements of Scrum

Sprints

As noted above, at the beginning of the sprint and to ensure openness and visibility, you need to create a special board and divide it into three columns:"Backlog"; "In progress"; " Made " . Before each sprint, team members stick in a column"Backlog" sticky notes with tasks they think they can complete in a sprint. During the sprint, any team member, having taken on a task, re-sticks the sticker from the section"Backlog" in the "In progress" column . After completing the task— in the “Done” column . This way everyone can see what other participants are currently working on.

However, there is an important note— « nothing is transferred to the column" Made " until this part of the project is tested by the client» .

« Another important aspect of the sprint: once the team approves the list of requirements, the tasks from this list „ are blocked“ . No one has the right to change them or make additions » . The author recommends this because of that any interference will slow down the team's work.

Daily meetings

The point is that they should be held standing, every day, at the same time, their duration should not exceed fifteen minutes, and participants should ask the same three questions:« What did you do yesterday to help the team complete the sprint?» , « What will you do today to help the team complete the sprint?» , « What obstacles stand in the way of the team?» .

Do it to the end

In Scrum, it is important to learn to feel the rhythm of the team. Worst case scenario— when at the end of the sprint something remains half done. It’s better not to start this business at all then.

« Resources, effort, time, money have been spent, but a fully functioning product has not been received » .

Planning in Scrum

How does the planning process work in Scrum? First you need to make a list of all the things that affect your goal. After that, prioritize them. If you do not meet the time and financial limits, then you can more easily eliminate the last items on the list.

What to do next? Each item on the list needs to be assessed for how much effort, time and other resources it will take to complete. How to make an assessment? The author proposes a scale of relative ratings. For example, you can compare tasks"in dogs". This problem - dachshund or retriever? Or maybe a Great Dane?

But in any case, it is more convenient to set numerical values. For example,« Dachshund— unit; Great Dane— thirteen; the labrador became a five, and the bulldog — three» .

The author also suggests using an interesting poker planning technique. Its essence— Each participant in the planning process is given a deck of cards with Fibonacci numbers— 1, 2, 3, 5, 8, 13 and so on. Each item on the list, a unit of work that must be evaluated, is laid out on the table.

Requirements are stories

In order to successfully and clearly formulate a list of product requirements and create a backlog for everyone, Scrum uses an extraordinary approach. Instead of a simple list of tasks, user stories are compiled— short stories containing user wishes for the final product.

« Imagine yourself making up „ Amazon.com user request “ . The trial version looks like this: „ As a consumer, I want the world's largest bookstore where I can buy any book at any time “ .This description fits Amazon's character well, but the story is too vague to be useful. somethingdo. We need to fragment our history. Make it really very specific and functional. Here are a few sample user stories you can write with the book in mind. online store :As a consumer, I like to search for books by genre to quickly find the ones I love to read. As a consumer, when I select books to buy, I want to put each one in my cart at once. As a product manager, I want to be able to track our customers' purchases , to be aware of what books can be offered to them. Here are professionally made user requests, the nature of which the group should take into account » .

The user story must be complete, independent of various circumstances, and implementable in practice. These criteria indicate the readiness of the story. It is also important that the story can be assessed for its feasibility.

How to plan a sprint

In Scrum, the planning process occurs at the beginning of each new sprint and is called— « sprint planning» . « Everyone gets together, looks at the list of user stories that are already in the queue for execution; find out how many tasks each group member can take on; carefully consider whether they will be able to bring the selected tasks to full readiness during this sprint; will they be able to demonstrate completed units of work to the customer and show him the finished functions of the product; Will they be able to tell themselves at the end of the sprint that they have managed everything? » .

After this, the team says in unison:" Forward! "— and gets to work

But what is work? Routine, obligation? From a Scrum point of view, work— this is history. What does it mean? This means that you should introduce someone who needs what you do; then what it is, and finally, why people need it.

Teams need to get to know their dynamics well— how much work she can complete in one sprint. This will help her work smarter and eliminate all obstacles in her way.

« Dynamics x time = result. Knowing how fast you're going will help you know when you'll reach the finish line » .

Openness in everything

Scrum assumes transparency of all actions and processes.

This is expressed in a three-column board that all team members have access to.

« Secrecy— I. Nothing can be kept secret. Everyone should know everything, including financial data. Obfuscation is necessary only for those who seek their own benefit. » .

Product Owner

Scrum assumes three roles: Scrum team - implementers of specific projects; Scrum Master - this is the one who monitors the progress of the project and helps the team solve problems, and the product owner— the one who solves the product concept issues and compiles the backlog.

« Scrum Masterand the team are responsible for the pace of their work and how quickly they complete the project. The Product Owner is responsible for ensuring that effective teamwork turns into profitable results. » . The Product Owner needs to have intimate knowledge of the market and must have the authority to make decisions.

This can be too much responsibility for one person, so large projects may involve a team of product owners.

Minimizing Risks in Scrum

Since Scrum provides for step-by-step project delivery, this helps minimize risks. This helps to quickly show the product to the client and receive feedback from him.

« The Scrum methodology is useful for business because it quickly answers the question: can we make money if we do this or that?”

You don't have to spend a lot of money before you realize something doesn't work.

This guide will help software developers and testers understand and get started with the Agile SCRUM methodology.

Learn the basic but important terms used in the Agile Scrum process along with a real-life example of the complete process.

SCRUM is an agile process that is a combination of iterative and incremental models.

One of the main disadvantages of the traditional waterfall model is that until the first stage is completed, the application does not move to another stage. If it happens that there are some changes at a later stage of the cycle, then it will be very difficult to carry out these changes, since it will entail revising the previous stages and redoing the changes.

Some of the key features of SCRUM are:

• Organized and purposeful team
• There are no document requirements, it is enough to have accurate texts to the point.
• The functional team works as a single unit.
• Close connection with the user, helping to understand the features.
• There is a precise time axis of maximum 1 month.
• Instead of doing everything at once, Scrum does a little bit of everything over a given period of time.
• Before taking any action, the characteristics and availability of resources are considered.

To understand this methodology well, it is important to understand the key terms of SCRUM.

Important SCRUM terms:

1. Scrum team

A Scrum team is a team of 7 +/- 2 members. Team members are a mixture of competent developers, testers, database people, support operators, etc., as well as the product owner and scrum master. All these people work closely together over a given recursive period to develop and execute the specified functions.

2. Sprint

A sprint is a standard period of time in which work must be completed and ready for review or product release. Typically this period takes from two weeks to a month. When we say that we do 1 sprint in a month, it means that we work for one month on tasks and prepare them for review by the end of that month.

3. Product Owner

The Product Owner is the main sales person or lead user of the application being developed.

The Product Owner is the person who represents the customer side. He/she has the final authority and must always be available to the team. He/she must be available when someone needs something explained. It is important for the product owner to understand and not set new requirements in the middle of the sprint or when it has already started.

4. Scrum master

The Scrum Master is the coordinator of the Scrum team. He/she ensures that the scrum team is productive and progressive. In case of any interference, the Scrum Master finds and resolves it for the team.

5. User story

User stories are requirements or functions that must be completed. In scrum we don't have these large requirements documents, on the contrary, the requirements are stated in one paragraph, usually in this format:

How<тип пользователя>

I want<доступная цель>

for achievement<результат/причина>

For example:

As an administrator, I want to be able to lock a password to limit unauthorized access in case the user enters the wrong password 3 times in a row.

There are some characteristics of user stories that must be adhered to. User stories should be concise, realistic, possibly evaluative, complete, negotiable, and testable.

Each user story has an acceptance criterion that must be clearly defined and understood by the team. Acceptance criteria describe user stories in detail and provide supported documents. This allows user stories to be detailed. Any team member can write down acceptance criteria. The verification team bases their test cases/conditions on these criteria.

6. “Epics”

Epics are vague user stories. Or, we can say that these are user stories that are not defined and are stored for future sprints. Just try to connect this with life, imagine that you are going on vacation. Since you're leaving next week, you've got everything planned: hotel reservations, sightseeing, travel bag packed, etc. But what about your vacation next year? You only have a vague idea that you can go to XYZ place, but you don't have any detailed plan.

“Epic” is like your vacation next year: you know that you can go, but where, when and with whom – there are no thoughts on this matter yet.

Likewise, there are features that should be implemented in the future, but their details are not yet known. Typically, an opportunity starts with an “epic” and is then broken down into stories that can be realized.

7. Product wish log

A product wish log is a kind of segment or source where all user stories are stored. It is maintained by the product owner. A product wish log can be thought of as a wish list from the product owner, who prioritizes it according to business needs. During planning (see next section), one of the user stories is taken from the backlog, the team begins to brainstorm, conceptualize, refine, and collectively decide (with input from the Product Owner) which user story to accept.

8. Sprint wishlist

One user story is taken at a time from the product wish log. The Scrum team brainstorms, determines feasibility, and decides which story to work on during a given sprint. The overall list of all the user stories that a Scrum team is working on during a given sprint is called the sprint backlog.

9. User Story Points:

These points are a numerical representation of the complexity of the user story. Based on these scores, the score and workload of one story are determined. Points are not absolute, they are relative. To ensure that our efforts and estimates are correct, we need to check whether the user stories are large. The smaller and clearer the user story, the more accurate the estimate will be.

Each user story is assigned a Fibonacci score (1, 2, 3, 5, 8, 13, 21). The higher the number, the more complex the story.

To be more precise, then

• If you bet 1 / 2 / 3 points, it means the story is short and has low difficulty.
• If you give 5/8 points then it is medium difficulty and
• 13 and 21 points – the story is very complicated.

The difficulty here lies in the development and the amount of testing work

To decide how many points to give, the Scrum team starts brainstorming and collectively decides. It may happen that the development team will give a specific story 3 points because for them it may be 3 lines of replacement code, but the testing team will give 8 points because they feel that this code replacement will have more impact on modules, so the amount of work there will be more during testing. But no matter how many points you give, you must justify your decision. Thus, a brainstorming session occurs and the team decides how many points to put.

Whenever you decide how many points to bet, consider the following factors:

• Relationship of history to other applications/modules,
• Resource Skill Set
• The complexity of history
• Narrative learning,
• User story acceptance criteria

If you are not aware of a particular story, do not resize it.
If you see that a story's score is very high, break it down into smaller stories.

10. Task burndown chart

A task burndown chart presents a graph that shows the estimated v/s of the actual effort of scrum tasks.

This is a tracking mechanism for a specific sprint. Every day tasks are tracked to check whether stories are progressing towards completion or not.

Example: To understand this, look at the picture:

I chose:

• Two Week Sprint (10 days)
• 2 resources for the actual work of the sprint.

"History" -> the column shows the user stories taken for the sprint. "Task" -> the column shows a list of tasks associated with user stories.

“Scope of work” -> the column shows the amount of work. This measure is now the total amount of work to complete the task. It does not depict the amount of work of any particular person.

“Day 1 – Day 10”->– column(s) shows the time remaining until the end of the story. Please note that this is NOT time that has already passed, BUT time that still remains.

“Estimated amount of work” -> indicator of the total amount of work. For "Start" this is simply the total of the entire task: SUM (C5:C15)

The total amount of work to be completed in 1 day is 70 / 10 = 7. Thus, at the end of the first day, the amount of work should be reduced to 70-7 = 63. Similarly, this is calculated for all days up to the 10th, when the estimated amount work must be zero (line 16)

“Remaining amount of work” -> As the name suggests, this is the amount of work remaining before the story is completed. It may also happen that the actual amount of work becomes more or less than expected.

You can use functions and charts in Excel to create this task burndown chart.

Task burndown chart stages:

1. Enter all stories (column A5 – A15)
2. Enter all tasks (column B5-B15)
3. Enter days (day 1 – day 10)
4. Enter the initial amount of work (sum up tasks C5-C15)
5. Apply the formula to calculate the “estimated amount of work” for each day (from day 1 to day 10). Enter the formula in D15 (c16-$C$ 16/10) and drag it to all days.
6. For each day, enter the actual amount of work. Enter a formula in D17 (SUM (D5:D15)) to sum up the remaining amount of work and drag it to all other days.
7. Select this and create a chart like this:

11. Team speed

The total number of points a scrum team stores in a sprint is called team velocity. A Scrum team is judged on its speed. It must be said that it should be borne in mind that achieving the maximum number of points is NOT the goal here, but good quality results increases the comfort level of the scrum team.

For example: For a specific sprint: the total number of user stories is 8. Each of them has a certain number of points

Thus, the speed is the sum of points = 30

12. Definition of “ready”:

History is MADE in Scrum only when there is development, full quality assurance and the opportunity to get into production.

Activities in SCRUM:

#1: Planning Meeting

The planning meeting is the starting point of SCRUM. This is a meeting where the entire Scrum team gathers. The product owner selects user stories from the product backlog based on priority and the team begins brainstorming. During the discussion, the Scrum team determines the complexity of the story and measures it according to the Fibonacci series. The team defines the tasks as well as the amount of work (in hours) that could be done to complete the implementation of the user story.

“Meeting Pre-Planning” precedes the meeting. This is like the homework that a Scrum team does before meeting for a formal planning meeting. The team tries to write down dependencies or other factors that they would like to discuss in the meeting.

#2: Completing Sprint Objectives

As the name suggests, it is the job of the Scrum team to complete its task and move the user story to the “done” status.

#3: Daily Scrum meeting (call)

During the sprint cycle, each day the scrum team meets for no more than 15 minutes (this could be a call, which is recommended at the beginning of the day). Three questions are asked at the meeting:

1. What has the team member done since the last meeting?
2. What does the team member plan to do today?
3. Are there any obstacles for the team?

The Scrum Master works to solve these problems. If a participant encounters any kind of difficulties, the Scrum master helps to solve them.

#4: Review of results

At the end of each sprint cycle, the SCRUM team meets again and demonstrates the implementation of user stories to the product owner. The Product Owner can collate the stories according to their acceptance criteria. It is again the Scrum Master's responsibility to chair this meeting.

#5: Retrospective Meeting

A retrospective meeting occurs after the review of the results. The SCRUM team gathers, discusses and documents the following points:

1. What went well in the previous sprint (best practice)
2. What wasn't done very well
3. Lessons learned
4. Action elements.

The Scrum team must continue to follow best practices, ignore “bad practices,” and implement the lessons learned in subsequent sprints. A retrospective meeting helps continuously improve the SCRUM process.

How is the process performed? Example!

Having read about the technical jargons of SCRUM, let me try to demonstrate the entire process with an example.

Step 1: Let’s imagine a SCRUM team of 9 people, consisting of 1 owner, 1 Scrum master, 2 testers, 4 developers and 1 database administrator.

Step #2: A sprint cycle, for example, will last 4 weeks. So, we have a 1-month sprint: from June 5 to July 4.

Step #3: The Product Owner has a prioritized list of user stories in the Product Backlog.

• The Product Owner takes 1 story from the product wish list, describes it, and passes it on to the team for brainstorming.
• The entire team discusses and goes directly to the product owner to explain the user story in detail.
• Other user stories are accepted in the same way. If possible, the team can continue and also measure the stories.

After the discussion, team members return to their workplaces and

• They define their individual tasks for each story.
• Calculate the exact amount of time they will need to work. How does the participant calculate this time? Let's check:

Total working hours = 9

Minus 1 hour for a break, minus 1 hour for meetings, minus 1 hour for emails, discussions, troubleshooting, etc.
So actual working hours = 6

Total number of working days during the sprint = 21 days.
Total available hours = 21 * 6 = 126

Member is on vacation 2 days = 12 hours (this varies for each member, some can take vacation, some can't.)
Number of actual hours = 126-12 = 114 hours.

This means that the participant will typically be available for 114 hours during this sprint. Therefore, he will divide his individual sprint task in such a way that it will be achieved in 114 hours.

• The final opinion on the user story from the product backlog is completed and the story is moved to the sprint backlog.
• For each story, each team member announces their specific tasks. If you want to discuss these problems, you can measure or resize them (think Fibonacci series!).
• The Scrum Master or team enters their individual tasks and their timing for each story into the program.
• Once all stories are completed, the Scrum Master marks the initial velocity and the Sprint officially begins.

Step #6: Once the sprint begins, each team member begins working on assigned tasks.

Step #7: The team meets daily for 15 minutes and discusses 3 questions:

• What did they do yesterday?
• What are they planning to do today?
• Is there any interference?

Step #8: The Scrum Master tracks progress daily using a Burndown Chart

Step #9: In case of any interference, the Scrum Master solves it.

Step #10: On July 4th the team meets again to review the results. Each team member demonstrates the implemented user story to the product owner.

Step #11: On July 5th the team meets again for a retrospective meeting where they discuss

• What went well?
• What didn't go well
• Action elements.

Step #12: On July 6th the team meets again for the next sprint pre-planning meeting and the cycle continues.

(Click to enlarge image)

Programs that can be used for SCRUM activities:

There are many tools that can be widely used to track scrum activities. Here are some of them:

• XPlanner
• VersionOne
• Sprintometer
• ScrumNinja

Conclusion:

In the beginning, people may face some difficulties trying to master this technique, but with practice, you will see that SCRUM works wonders. SCRUM focuses resources so you can see your application evolve.

Many temporary organizations encourage the team (as a scrum task) to dedicate a couple of hours to self-learning and development. Also during the review, group members show what they have learned and sometimes present programs or applications they have developed. Personally, I value this method because it gives people a chance to expand their knowledge as well as show off their skills.

I am continuing to work on my dissertation in project management. Today we will take a quick look at Scrum, looking at common mistakes that lead to problems. This post does not pretend to be complete, it is an overview and is addressed to those who are not yet familiar with Scrum, or are only partially familiar (for example, they work in a modified Scrum).

Currently, Scrum is one of the most popular software development methodologies. By definition, Scrum is a development framework that allows people to solve emerging problems while being productive and producing products of the highest value.

This suggests that in Scrum it is impossible to find answers to all questions and instructions for action in all situations (for example, the official description of Scrum only indicates the need to estimate the time required to complete the work, but does not specify the type of estimate. i.e. this could be planning poker or another method of assessment). Thus, the name of the topic itself is not correct :)

When they talk about the Scrum methodology, they most often mean a flexible software development methodology built on the basis of the rules and practices of Scrum, so it may well turn out that your Scrum is cooler than my Scrum, and also be as far from it as VAZ 7 is from BMW 7 Series:)

Roles in Scrum

In classic Scrum there are 3 basic roles:
-Product owner
-Scrum master
-Development team

Product owner(PO) is the link between the development team and the customer. The PO's job is to maximize the value of the product being developed and the team's work.

One of the main PO tools is the Product Backlog. The Product Backlog contains work tasks required for execution (such as Story, Bug, Task, etc.), sorted in order of priority (urgency).

Scrum master(SM) is a “servant-leader”. The Scrum Master's job is to help the team maximize its effectiveness by removing obstacles, assisting, training and motivating the team, and assisting the PO

Development team(Development team, DT) consists of specialists who directly work on the product being manufactured. According to The Scrum Guide (a document that is the official description of Scrum from its authors), DTs should have the following qualities and characteristics:
-Be self-organizing. No one (including SM and PO) can tell the team how to transform the Product Backlog into a working product
-Be multifunctional, have all the necessary skills to release a working product
-The entire team is responsible for the work performed, not individual team members

The recommended team size is 7 (plus or minus 2) people. According to Scrum ideologists, larger teams require too many communication resources, while smaller teams increase risks (due to the possible lack of required skills) and reduce the amount of work that the team can complete per unit of time.

Scrum process

The basis of Scrum is the Sprint, during which work on the product is carried out. At the end of the Sprint, a new working version of the product should be obtained. Sprint is always limited in time (1-4 weeks) and has the same duration throughout the life of the product.

Before the start of each Sprint, Sprint Planning is carried out, which evaluates the contents of the Product Backlog and generates a Sprint Backlog, which contains tasks (Story, Bugs, Tasks) that must be completed in the current sprint. Each sprint should have a goal, which is a motivating factor and is achieved by completing tasks from the Sprint Backlog.

Every day a Daily Scrum is carried out, in which each team member answers the questions “what did I do yesterday?”, “what do I plan to do today?”, “what obstacles did I encounter in my work?” The task of the Daily Scrum is to determine the status and progress of work on the Sprint, early detection of emerging obstacles, and develop solutions to change the strategy necessary to achieve the Sprint's goals.

At the end of the Sprint, Sprint Review and Sprint Retrospective are carried out, the task of which is to evaluate the effectiveness (performance) of the team in the past Sprint, predict the expected effectiveness (performance) in the next sprint, identify existing problems, assess the likelihood of completing all necessary work on the product, and more .

A schematic representation of the process is shown in the following figure:

Important, often forgotten features

You often hear that Scrum doesn't work, or works worse than expected. It should be noted that most often this happens for one of the following reasons:

1. Scrum is applied incorrectly or incompletely.
According to the authors of Scrum, empirical experience is the main source of reliable information. The need for complete and accurate implementation of Scrum is indicated in The Scrum Guide and is due to the atypical organization of the process and the absence of a formal leader and manager.

2. The importance of working to motivate the team is underestimated.
One of the core principles of Scrum is self-organizing, cross-functional teams. According to research by sociologists, the number of self-motivated employees capable of self-organization does not exceed 15% of the working population.
Thus, only a small proportion of employees are able to work effectively in Scrum without significant changes in the Scrum Master and Product Owner roles, which is contrary to the Scrum ideology, and potentially leads to incorrect or incomplete use of Scrum.

3. Scrum is used for a product whose requirements contradict the Scrum ideology.
Scrum belongs to the Agile family, so Scrum welcomes changes in requirements at any time (the Product backlog can be changed at any time). This makes it difficult to use Scrum in fixed-cost/fixed-time projects. The Scrum ideology states that it is impossible to foresee all changes in advance, so there is no point in planning the entire project in advance, limiting ourselves to just-in-time planning, i.e. Plan only the work that must be completed in the current Sprint. There are other restrictions.

Advantages and disadvantages

Scrum has quite attractive advantages. Scrum is customer-focused and adaptive. Scrum gives the client the ability to make changes to requirements at any time (but does not guarantee that these changes will be implemented). The ability to change requirements is attractive to many software customers.

Scrum is quite easy to learn and allows you to save time by eliminating non-critical activities. Scrum allows you to get a potentially working product at the end of each Sprint.
Scrum emphasizes a self-organizing, cross-functional team that can accomplish required tasks with minimal coordination. This is especially attractive to small companies and startups as it eliminates the need to hire or train specialized management personnel.

Of course, Scrum also has important disadvantages. Due to its simplicity and minimalism, Scrum sets a small number of fairly strict rules. However, this conflicts with the idea of ​​customer-centricity in principle, since the client does not care about the internal rules of the development team, especially if they limit the client. For example, if necessary, by decision of the client, the Sprint backlog can be changed, despite the obvious contradiction with the Scrum rules.

The problem is bigger than it seems. Because Scrum belongs to the Agile family; Scrum does not, for example, create a communication and risk response plan. Thus, making it difficult or impossible to formally (legally or administratively) combat violations of the Scrum rules.

Another weak feature of Scrum is its emphasis on a self-organizing, cross-functional team. Despite the apparent reduction in costs for team coordination, this leads to increased costs for personnel selection, motivation, and training. Under certain labor market conditions, forming a full-fledged, effective Scrum team may be impossible.

List of sources used

The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
Psychology of management, textbook. (A. A. Trus)
How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)

Thank you in advance for these errors and inaccuracies!