What is it?

Product Backlog

The only sorted list of Product requirements. That is, the list of all possibilities and features that interested people want to see in the Product.

Sprint Backlog

A list of actions to realize the selected elements of the Product Backlog, that is, a list of improvements the Team will do in the nearest Sprint and a description of how they will implement these improvements.

How do they look like?

Somehow! It should be easy for the Team to work with them. Most often a Backlog is a worksheet or table in Excel, a board with stickers, a virtual board in Trello or Jira.

What do they include?

The “Fight club” company organizes broadcast of boxing matches. They have a website where users watch records of previous fights and live broadcasts. Some kind of YouTube for boxers.

Product Backlog

New features or functions of the Product.

The highest priority in the “Fight club” Product Backlog is: the customers should be able to put the bets on their favorite fighters to make more profit.

Sprint Backlog

Real steps to achive the Sprint Goal.

In the Sprint Backlog the Team devides a big betting task in the specific steps:

• add a new section on the site;
• attach online payments;
• find out, how to transfer funds to the winners;
• test, how it works;
• gather the feedback.

Who does make it?

Product Backlog

The Product Owner

Sprint Backlog

The Development Team

Who does influence the content?

Product Backlog

The Product Owner. He may take into consideration the opinion of stakeholders and customers, but the final decision and responsibility for the Product Backlog lies on him only.

Sprint Backlog

The Development Team. Nobody else may add to or remove the tasks from the Sprint Backlog.

When being created?

Product Backlog

On the very first Sprint Planning.

Sprint Backlog

On each Sprint Planning.

When being changed?

Product Backlog

The order of the Product Backlog elements and their detail level may be changed on Sprint Planning, Spring Review or Product Backlog Refinement. New ideas can be added to and some previous ones can be removed from the list.

Sprint Backlog

Changes in the Sprint Backlog depend on the speed of the Team work. They may happen even every day. Important: the changes appear due to the fact that the Team devides the tasks into smaller ones or understands that it is necessary to do something else to achieve the Sprint Goal.

How long does exist for?

Product Backlog

Until the Product is actual.

Sprint Backlog

During one Sprint(1–4 weeks).

How many teams use it?

Product Backlog

The only Product Backlog inspite of number of teams.

1 Product-1 Product Backlog-several Teams

Sprint Backlog

Each Team has its own Sprint Backlog. If we have five Teams, we have five Sprint Backlogs then.

1 Product-several Sprint Backlogs-several Teams

Whether it ends by the end of the Sprint?

Product Backlog

No. New elements will appear in the Product Backlog as the Product exists on the market.

Sprint Backlog

Yes. In theory, all the Sprint Backlog elements should be done by the end of the current Sprint.

The detail level

Product Backlog

The upper Product Backlog elements are detailed better than those on the bottom.

Sprint Backlog

All the Sprint Backlog elements are detailed approximately in the same way.

Now, let us repeat it shortly:

The Product Backlog is the list of Product improvements, sorted by priority. It is made by the Product Owner who considers the opinion of stakeholders and customers if he wants. The Product Backlog exists as the Product exists on the market.

The Sprint Backlog is the action list for the nearest Sprint which is made by the Development Team. In the Sprint Backlog the Team describes the specific steps by which it will implement the elements of the Product Backlog. Each Sprint the Team creates a new Sprint Backlog.

Prompts

Remember

The Product Backlog is the list of Product improvements, sorted by priority.

The Sprint Backlog is the list of specific steps to implement the selected Product Backlog elements.

Original text:

http://www.agilebasics.ru/backlogs/

Got an idea or a project? Hire the Agile Software development team. No-Risk

Work with the best agile design and development teams.

Hire the team — get first delivery in 2 weeks.

Product Backlog and Sprint Backlog. What is the difference? was originally published in Eulerr on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Product is something that creates a certain value for the customers as well as for the company that produces it.

The Product can be:

• physical object (chair, pie, newspaper);
• digital product (Microsoft Office, e-book or streaming video);
• service (house cleaning, consultation on profitable investment);
• idea (how to get more date invitations in the Dating app, how to make money on production waste).

Why is it so important to understand what the Product is?

The Product specifies everything:

• institutional framework, that is, how the company will be organized — how many departments will be required, how they will interact and so on;
• the Product Owner selection;
• the number of teams that will be required to produce the Product;
• employees necessary skills.
  Errors in the Product definition, will inevitably lead to problems in the future, so it is vital to make no mistake in this step.

The real Product criteria

All the products can be divided into external (market) and internal ones. We can buy external products in the store or on the site, and internal products are created inside the company to improve its performance. Each type of products has its own criteria.

Real external product:

• solves a specific problem or creates benefits for a group of users and customers, for example, Google solves the problem of Internet information search;
• has key features (functionality);
• the Product has a clear business model that brings profit. It may be direct income-you buy a licensed Microsoft Office Pack and Microsoft company receives money. Income may be indirect-a free Google Chrome browser helps to sell other Google’s products and services.

Real internal product:

• established for people who really use it;
• creates evident business benefits, for instance, the internal product “assembly line” hasten the car assemble process on Ford factories.

It is important to understand at the very beginning what Product you are doing and make sure it is real!

The Product is not the same to project

It seems like they are the same, but they are really not. Remember: the Product solves the problem and the project is only a stage of creation, implementation or advancement of the Product.

Let’s have a look at the Windows operating system. It is a Product that allows people to use the computer. Windows is periodically updated: Windows Vista followed by Windows XP, which in its turn followed by Windows 8 and Windows 10. Each system update is a new project. Windows XP and Windows 10 are projects. And the Windows operating system itself is the Product.

The Product and the project have different lifetimes. In theory, the Product can live forever, but in reality we focus on 5–10 years. The project usually lasts much less and has a clear start and end date.

The first version of Windows was created in 1993, it means the Product exists for about 25 years (a quarter of a century already). At the same time, each version of Windows existed from one to five years only.

The Product and the project have different success criteria. The project will be successful if the promised functionality is created in time and within the budget. The only one criterion of the Product success is whether it is profitable.

The “Titanic” movie was a failed project, because the crew missed all the established deadlines, exceeded the budget and finally this movie was not made as the authors have intended in the beginning. But as a product “Titanic” achieved incredible success, because it had one of the best box office in history.

Be sure to check if your Product solves the customer’s problem.

The Product is not the same to functional improvement

It happens that any improvement is called the Product by developers. It is wrong. If something the Team is currently working on does not bring value for the customers without other parts of the system, it cannot be called the Product.

Take AliExpress, for example. It has a product search engine and although it is an important part of the store, separately the search is just the store function, but not the Product. No one comes to AliExpress just to search for something, people come there to buy cheap goods.

If a Product does not bring benefit by itself, it is not a Product.

The Product is not the same to distribution channel

Rather often, the real Product is confused with the delivery channel to the customer. Of course, in the case of bakery one will hardly allocate delivery service into a separate Product. But, the situation with intangible products is not so obvious.

Take a Bank, for instance. It has a website and a mobile app. Will the app be a separate product for the Bank? No. And a website? Also no, because the site and the app simply help clients to buy the real Bank products: loans, deposits and mortgages.

To distinguish the Product from the distribution channel, try to understand if the customer can solve his problem without it? If you delete the application, the one will still be able to make a deposit in the Bank department. So, the application is the distribution channel of the Product.

Let us underline it one more time, if a Product does not bring benefit by itself, it is not a Product.

The Product determines what your company will look like, how many people will work in it and much more. It is better to spend time and deal with it in the beginning than to fix the problems that will inevitably appear when the Product is incorrectly defined.

Prompts

Remember

• The Product is something that creates a certain value for the customers as well as for the company that produces it.
• The Product specifies the institutional framework of the company, the Product Owner and employees selection and number of the teams.
• Profit is the main Product success criterion.

Original text:

http://www.agilebasics.ru/product/

Got an idea or a project? Hire the Agile Software development team. No-Risk

Work with the best agile design and development teams.

Hire the team — get first delivery in 2 weeks.

The Product in Scrum. What is it? was originally published in Eulerr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Define the purpose of the meeting

In the Scrum Guide we show you how to organize mandatory meetings like the Daily Scrum or the Sprint Retrospective. They are already spelled out in the Scrum Guide: all the participants know why, when and who is going to meet in advance. We propose to establish the same clear rules in case the meeting is dedicated to some working issue and is not mentioned in the Guide.

First of all, define the purpose of the meeting: it motivates and helps participants to prepare. It makes no sense to meet without a purpose.
Usually, the participants of the meeting want to find a way out of the impasse or decide how to take an advantage of the opportunity.

Mark the result desired

Indicate the desired result in the form of a 3–5 detailed items to understand whether you reached the goal. The result differs from the goal because it can be seen and touched.

It is not a result to review the strategy for the fourth quarter or to enlist support of the management. If you gathered because of the problem, you should make a list of possible actions for your situation by the end of the meeting. And if you discuss a profitable partnership, the real result will be to sign the contract.

Make the agenda

To achieve the desired result, make the agenda of the meeting. This is the item schedule of the meeting, preferably per minute.

For additional clarity, the agenda is made in the form of a table. It indicates the participants of the meeting, the issues to be discussed and the time that is devoted to each issue.

Choose a moderator

Choose a moderator if you want the meeting to be held according to initial plan. He is responsible for the process: he looks whether the participants “fall out” of the agenda and helps to achieve the desired result.

The ideal moderator will focus you on the goal, involve in discussion, make sure that all ideas are recorded and not impose his own opinion. Cheer you and point the perfect direction,if necessary.

Expand these rules

This minimum set of rules is enough to change the attitude to such meetings in a couple of weeks. But you will achieve more if you add to it something new.

It depends on the specifics of your company to determine which settings to add. Probably some meetings will need more preparation, new roles or even special seat arrangement at the table.

Original text:

http://www.agilebasics.ru/effective-meetings/

Got an idea or a project? Hire the Agile Software development team. No-Risk

Work with the best agile design and development teams.

Hire the team — get first delivery in 2 weeks.

How effective meetings in Scrum should be held was originally published in Eulerr on Medium, where people are continuing the conversation by highlighting and responding to this story.

We use the Scrum rules incorrectly

Scrum is very often used incorrectly. For example, the size of the Development Team is more than nine people, the Product Owner does not have the power and ability to make decisions on the Product, the Team does not conduct a Sprint Retrospective. No wonder that in these cases the use of Scrum will be useless.

It also happens that formally all elements of the Scrum are observed, but the company does not follow the values of the Scrum: devotion, courage, focus, openness and respect. What is obtained as a result, called mechanical Scrum. It does not bring any special benefit to the company.

We are not ready that real Scrum hurts

The Scrum brings to the surface existing problems, and we think it was just the Scrum that ruined everything.

For example, the Product Owner closed the project after the first Sprint. We can say: “Look, as soon as they started using Scrum, the project has blown up!” That is not quite true. Based on the speed of the Team and estimated of its future speed, the Product Owner realized that the project will be delayed and will not be profitable. The Scrum saved a company a lot of money by the bad project has been stopped at early stage. The Scrum caused a “ benign pain.”

We think that everything will work fine from the first Sprint

In the first Sprint, the Team usually has a mess. It takes time for the Team to start interacting effectively.

It is so easy to say that the Scrum does not work: “Hey, look at this mess! The team did not do anything useful for this Sprint, they argued about the numbers on the stickers for the half of time!” But be patient, give the Team time to make mistakes and learn more from them.

We try to adapt the Scrum for ourselves

If you make the scrum “like in a book” and beat your head on the same problem for several months, you really want to create your own version of the Scrum. Of course, you can change the rules, but it will be not the Scrum any more, but something else.

It can be like that too. But please look carefully-sometimes the problem can be solved by increasing the facilitation or by talking openly about it’s reasons. Do not blame the Scrum. Most often, an honest look at the problem helps to fix it.

We use the Scrum where it does not work.

There are some areas in which the Scrum simply does not fit.

Suppose we have a technical support. Every day it changes something in the program: fixes the problems or improves the details. These changes may not be collected in the Sprints, because priorities change very often.

When the Team has time, it works on long-term improvements. These long tasks also do not fit into the Sprint with their sizes. In this context, the Sprints and the Sprint Planning will be a waste of time.

Scrum is not the only way to move to Agile. Try Kanban, sign up for our basic training.

Original text:

http://www.agilebasics.ru/scrum-errors/

Got an idea or a project? Hire the Agile Software development team. No-Risk

Work with the best agile design and development teams.

Hire the team — get first delivery in 2 weeks.

Five typical errors if you work on Scrum was originally published in Eulerr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last years, Russian software developers are very famous all over the world. They are talented specialists, they can think outside the box, be creative, purposeful and be able to work in a team. In the Universities typically there are special departments, which specialize ONLY in solving abstract Olympiad problems. Studying there is free, but in order to get in, you need to win a contest. Only 1 in 500–1000 students is accepted and from eligible specialties only (math and computer science). No wonder, that they win such contests repeatedly.

It is not a secret that many international programming contests are dominated by developers from Russia. Google Code Jam, Microsoft Imagine Cup, the Central European Programming Contest(CEPC), Top Coder — Russian Developers steadily get the highest ranks in these prestigious events. They are currently ranked 1st in the world in the Top Coder ranking and 2nd at Hacker Rank.

There is a proverb on the Internet that shows the level of trust to Russian developers. It says:

“If you want to solve a programming problem, pass it to American programmers. If you want to solve a hard programming problem, pass it to Chinese programmers. If you want to solve an impossible programming problem, pass it to Russian programmers!”

And that is exactly true!

With strong educational background, one of the highest development skills in the world, good command of English language, caring about good communication, with high security standards and relatively low price, Russian agile design and software development teams seem to be one of the best variant to entrust your software and design development tasks to.

While Agile thinking goes around the world, Russian software developers are those who clearly understand the benefits of Agile approaches to solve any level complex tasks. Most of the developers consolidate in the small cross functional teams which strictly follow the principles of Scrum in their work, share Scrum values. They are purposeful, talented, educated people who can think and act originally, going beyond the usual patterns. They are well-known workaholics and you will not find boring people who “serve” their time in the workplace among them.

Ideas are discussed, tested and implemented with stunning enthusiasm and speed. Meetings, which may take several hours to complete at other enterprises, are transformed into a thematic discussion at lunch. And only a few walls separate those who create the source code from those who write checks. Such an environment of open communication contributes to the growth of productivity and friendly relations. At on often speak: give necessary tools to people who love to create, and you will see that they are capable of a lot of things.

Of course, nowadays the decision to hire the agile design and software development team from Russia may seem some kind of madness because of US mass media hysteria about Russian hackers’ intervention in the US president and Congress election. Mass media form the atmosphere of horror and fear in relation to Russia. They sow the seeds of distrust and phobia in public opinion. It seems that starting to cooperate you will get big problems from powerful government and public institutes.

To tell the truth many usual things are different. Another language, different time zone, another currency and living environment. In addition, “sensational” election intervention.

But, the judicious point of view is that the most important things are a well-done code, mandatory, reliability and competitive price. Now, you may hire high class specialists for even lower price than in USA due to USD/RUB rate.

Russian software developers have all main features mentioned above. Thus, to hire the agile design and software development team from Russia can be the best investment for you now.

Got an idea or a project? Hire the Agile Software development team. No-Risk

Work with the best agile design and development teams.

Hire the team — get first delivery in 2 weeks.

Why аre Russian software developers the best in the world to invest your money in? was originally published in Eulerr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Without a retrospective, no one seems to be wondering whether everything is OK. Nobody is going to ask the opinion about the workflow. The reason of errors is not considered to be in it, but in the actions of employees. Subordinates usually keep silent, even if they do not like something . Eventually, these innuendoes will affect the result. The Sprint Retrospective eliminates this.

Meeting of the entire Scrum Team on equal terms

The Product Owner, the Development Team and the Scrum-master present on the Sprint Retrospective. They participate in conversation on equal terms.

Meeting is mandatory for all. It is impossible to coordinate the Readiness Criteria without the Product Owner and without the full Team presence to know about all the problems and omissions. The Scrum-master is also involved in the discussion-he shares his impressions about the work on the principles of Scrum with other participants of the meeting.

The editors in editorial office hold a Sprint Retrospective once a week. Editor-in-chief in the role of the Product Owner, the four editors and the Scrum-master present at the meeting.

At one such meeting, the editor-in-chief said there were too many tasks for now and offered to transfer them to the Scrum Board. The editors discussed how to work with the tool and implemented it in the next Sprint. Now the tasks and workflow are always in full view.

All the participants speak on the Sprint Retrospective

Helps to improve the workflow

At the meeting, the participants assess how the work was done in the Sprint, how the tools have been suitable and what relationships have developed within the Team. Immediately, the Product Owner and the Development Team decide whether they need to revise the Readiness Criteria or they are enough to stop the hack work and make a truly finished Product.

As a result, each participant of the meeting clearly understands what was good and what went wrong. Based on this understanding, they come up with a plan to improve the workflow in the next Sprint, which will help to increase the efficiency of the Team and the quality of the Product.

The Sprint Retrospective takes place in a friendly atmosphere. Even if something failed in the Sprint, at the meeting no one is looking for the guilty person-they solve the problem only.

At the next Sprint Retrospective the editor said it was inconvenient for her to collect the tasks for the illustrator from all other members and transfer them in a stack. More over, it significantly slows down the rest of the work. All agreed to turn to the illustrator directly. As a result, the speed of work increased in the next Sprint.

The meeting participants think about improving the processes, tools and interaction.

Lasts not more than three hours

The Sprint Retrospective is carried out after the Sprint Review and before the next Sprint Planning. If the Sprint lasted for a month, the meeting lasts for three hours. If the Sprint took shorter time it can take less time for its Retrospective.

The Scrum-master ensures the participants of the meeting keep within the allotted hours, although he is involved in the discussion. At the same time, he does not allow to lose focus.

The editors are gathered in the morning on Thursdays, communicate for about an hour. If they start, for instance, talk about spending their private time, the Scrum-master returns them to the workflow discussion.

At the meeting, the participants do not waste time on solving the problems in relationships and personal issues.

The Sprint Retrospective is a useful meeting. On it the Scrum Team discusses how to improve the workflow process and the climate within the Team to improve the Product itself.

We have already told how the rest of the meetings are held in Scrum: Sprint Planning, Daily Scrum, Sprint Review.

Prompts

Remember

• The Sprint Retrospective is a meeting on equal terms for the entire Scrum Team.
• The participants of the meeting discuss how the work proceeded in the Sprint and how to improve it.
• The meeting lasts not more than three hours.

Original text:

http://www.agilebasics.ru/sprint-retrospective/

Got an idea or a project? Hire the Agile Software development team. No-Risk

Work with the best agile design and development teams.

Hire the team — get first delivery in 2 weeks.

What is the Sprint Retrospective was originally published in Eulerr on Medium, where people are continuing the conversation by highlighting and responding to this story.

At a regular meeting, they want to report more often than to receive feedback. And while one speaks about the work performed, the rest are bored at best and make comments the authorities to notice at worst. Such remarks look like attack and provoke a dispute. The Sprint Review is different.

The interested persons are trying the Product

On the Sprint Review, stakeholders joined the Team. The Product Owner invites everyone who can assess the quality of the Product and offer improvements, based on the market changes also. The Scrum-master ensures the Sprint Review takes place and helps the participants to achieve the goal.

The Team says what kind of problems they faced up, how they solved them and what result was achieved during the Sprint. Users, customers, managers and other team members try the Product, evaluate how it is worked out and what is missed. Then they propose what can be added to the Product next Sprint.

The Team receives feedback directly

The Product Backlog is revised

The Team and stakeholders discuss the Backlog. They share their thoughts about what to do the nearest Sprint, what it will cost to the company and whether it will be in demand among customers.

The Product Owner summarizes what has already been done and what else is necessary to be done to increase the value of the Product. Based on the progress of the Team, he assigns the date of the Product update or release it to the market.

At the end of the meeting, all participants clearly understand what the Team will focus on.

Meeting is gathered to understand how else to improve the Product

It takes up to 4 hours

If the Sprint lasted for a month, the meeting can take four hours. But for short Sprint its Review needs less time.The shorter the Sprint, the shorter its Review.

The Scrum-master ensures the meeting participants keep within the allotted time. If the conversation goes to another topic, the Scrum-master offers to discuss it separately.

Duration of the meeting depends on duration of the Sprint

The Sprint Review is an unofficial meeting to obtain feedback from the stakeholders. Thanks to it the Team understands how to improve the Product and make it more useful.

How the regular meetings are held during the Sprint, we told in the article “What is the Daily Scrum”.

Original text:

http://www.agilebasics.ru/sprint-review/

Got an idea or a project? Hire the Agile Software development team. No-Risk

Work with the best agile design and development teams.

Hire the team — get first delivery in 2 weeks.

What is the Sprint Review was originally published in Eulerr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Daily Scrum replaces those meetings, where it is important for the boss to let steam off and to show who is in charge here and for the subordinates — to convince him that everything is all right, where the chief gives kicks and tasks and subordinates are justified, quietly playing their smartphones and think about the end of a meeting. As a result, half an hour and even more is wasted. The Daily Scrum is different.

Only the Team members participate in it.

All the Team members should present at the Daily Scrum. If even one does not come, it will not be possible to assess the progress towards the Sprint Goal and coordinate the next steps. Meet in person — it is possible to miss something in correspondence or understand each other incorrectly. The Scrum-master monitors the meeting to be held.

All employees are allowed to come to the Daily Scrum, but the Team only is involved in discussion. The Scrum-master and the Product Owner also do not interfere. Their presence at the meeting is not necessary.

Other people may mislead the participants from the topic, therefore, have no right to discuss. The Scrum-master and the Team make sure that no one interferes here and are listened to the comments on the Sprint Review only.

For instance. The Sprint Goal of the engineers Team is to assemble the battery for electrocar.

Correct way

• All engineers come, and no one distractes them from discussion. Agreed to decide during the day how many cells they need and how to fit them in the battery.
• Next day, engineers proceed from the ready pattern.

Wrong way

• One engineer did not come, another sent a report by mail. The Scrum-master told about the upcoming work on the battery.
• Engineers did not find out what the Team had already done and what their colleagues had been working on.

Participants meet in person, so that nothing is going to be missed.

The main idea is to check

On the Daily Scrum, participants check how close they are to the Sprint Goal and what actions they will take now. The format of the meeting is determined by the Team itself. Participants may have a discussion or take turns and tell what they have done since the last meeting, what they will do to the next one and whether they see any obstacles on their way.

Everybody says, because in the Team all depend on each other. The participants do not consider the meeting to be formal, but try to join efforts for the Sprint Goal.

Engineers work on assembling the battery of electric car. Now it is time to test the damage protection.

Correct way

• Everyone spoke at the meeting. One engineer said that yesterday he learned about high cost of the second sample. For tests was decided to take a cheaper version.
• By the next meeting they got the result.

Wrong way

• The first tests did not give a result. The Product Owner wrote in chat to test a second sample today. A couple of engineers agreed, the rest did not answer.
• As a result, later they found out a second sample is not suitable because of the high cost.

Every participant will know where the Team is moving and how he will help it.

Takes 15 minutes

The meeting takes not more than 15 minutes. It motivates participants to prepare in advance and speak on topic only. The Scrum-master controls duration of the meeting and the Team has achieved its main task-the Sprint Goal way had been checked and verified.

If there is a problem, it is recorded, but is not immediately solved. After the meeting, the Team agrees who and when will discuss this problem.

Engineers came up with cells to use in the battery, how to fit and protect them. Now they think how to fix the battery inside the electric car.

Correct way

• The engineer identified the problem with the mount, it was recorded, but did not discuss it at the meeting anymore. Same day, the Team spoke to an expert and found out a solution.

Wrong way

• One engineer said that the mount is not suitable due to the low center of gravity, and the meeting flowed into this problem discussion. Solution was not found out yet.

The meeting takes 15 minutes for participants to focus on the topic.

The Daily Scrum is not just a planning meeting. It helps the Team to organize their work and achieve the Sprint Goal in the shortest possible way.

How the Team and workflow are arranged, we told in the article “What is scrum”.

Prompts

Remember

• No one except the Team members has the right to discuss on a Daily Scrum.
• The team analyzes the progress towards the Sprint Goal and plans the work for the day.
• The meeting takes 15 minutes and takes place every day at the same time.

Original text:

http://www.agilebasics.ru/daily-scrum/

Got an idea or a project? Hire the Agile Software development team. No-Risk

Work with the best agile design and development teams.

Hire the team — get first delivery in 2 weeks.

What is the Daily Scrum was originally published in Eulerr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Finally, people stopped to carry money in a pyramid scheme — now more and more people are looking for a reliable source of income. One big bank decided to come up with a new service for customers-the purchase of shares, bonds or currency. But to make it more convenient, there should be a section in the Internet Bank.

With Sprint Planning

• The participants came to the meeting responsibly. The Product Owner spoke about the purpose of the business and the Team sat down to discuss the future work.
• Immediately understood, that simple section is not enough.

Without planning

• The Manager briefly gathered the performers, told about the project and gave instructions. The performers obediently started their work.
• No one paid close attention to the problem, but in vain.

Mandatory meeting for all

The Product Owner, the Development Team and the Scrum-master are needed on Sprint Planning. Let’s see what roles they play there.

The Product Owner speaks first. He voiced the agenda and explains what next Sprint to focus on. The team, based on his words, discusses the action plan. The Scrum-master is responsible for all participants were present at the meeting and understood their roles, but he does not enter the conversation.

With Sprint Planning

• The Scrum-master made the whole Team to present at the meeting: bank analysts, designers and programmers. Analysts told about customers who are ready to invest, but do not know how to do it.
• Thus, the Team found that it is necessary to add in section an expert advice.

Without planning

• The Manager called for a meeting designers and developers, but did not wait for analysts, more over they can always be met separately.
• That is why no one said that the instrument for investment only was not enough.

They will not be able to plan the Sprint fully even due to the lack of one person.

Planning helps to determine the purpose and scope of the work

The Development team and the Product Owner discuss business interests and determine the purpose of the Sprint. It will show the meaning of the future work.

Only the Team decides how many tasks to take in the Sprint. Based on their own experience they predict how many they can provide. The Team takes the tasks from the Product Backlog-they are already sorted according to their importance. As a result, the Team makes the Sprint Backlog: a list of tasks and an indicative plan how to resolve them.

When there are too many or, conversely, very few tasks in the Sprint Backlog, the Product Owner connects to the Team. He helps to highlight the most important ones.

With Sprint Planning

• The Team admitted that it will not fulfill all the wishes of the business in one Sprint.
• Agreed that they will provide an opportunity to buy shares first and planned the start of the Sprint.

Without planning

• The Manager was in such a hurry to start the project that he distributed all the tasks he had and set the most optimistic deadline.
• By the end of the week it is close to collapse.

The Sprint Goal is determined on the basis of business interests, the scope of work-based on the speed of the Team.

The meeting can take place for two hours, but sometimes even eight

Up to eight hours can be reserved for Sprint Planning, but only if the Sprint lasts for a month. If less, the meeting ends faster. It may seem that the participants are wasting so much time, but this is an important job. It depends just on the Sprint Planning whether the Development Team will succeed. So if necessary the meeting lasts all day long.

The Scrum-master makes sure the time on Sprint Planning is spent usefully. When participants forget about the topic, he brings the conversation back to a constructive course. The task of the Scrum-master is to explain the Product Owner and the Team the importance of the meeting and help them to coordinate the Goal and the Sprint Backlog in the allotted time.

With Sprint Planning

• The participants understand that the meeting is as important as the rest of the work. They released for it one day and are not going to miss next month.

Without planning

• The Manager held a meeting in less than an hour. The performers were happy-they did not want to waste time on empty chatter.
• They will gather more than once to correct mistakes in the plan.

The main thing is that the Goal and the Sprint Backlog must be coordinated by the end of the meeting.

Sprint planning is a mandatory Scrum event. What the Product should look like by the end of the Sprint and how to achieve it is decided on it.

Read also, how to conduct the Daily Scrum or Sprint Review.

Prompts

Remember

• On the Sprint Planning the Product Owner, Development Team and the Scrum -master formulate the Goal and compose the Sprint Backlog.
• Meeting takes place for not more than eight hours.

Original text:

http://www.agilebasics.ru/sprint-planning/

Got an idea or a project? Hire the Agile Software development team. No-Risk

Work with the best agile design and development teams.

Hire the team — get first delivery in 2 weeks.

What is the Sprint Planning was originally published in Eulerr on Medium, where people are continuing the conversation by highlighting and responding to this story.

The development with the help of Sprints:

• makes the Product and business flexible. You can change the Product in each cycle and adjust it at any time to the wishes of customers and market conditions.
• keeps the mindset of the Team. All employees understand what stage the Team is at and what will happen next. All necessary things are prescribed and limited in time. There is no confusion, but a reasonable organization of the workflow process.
• accelerates the achievement of the desired result. In addition to the Team, people who make decisions on the product participate in the Sprint. The team does not need to wait until their actions will be agreed with the management.

The Scrum Guide says that the Sprint could not be shorter than one week and longer than one month. This restriction specifies a time frame that is sufficient to create the finished Product and that is rather safe for the company if the Product will be unclaimed and irrelevant. According to the experience of our coaches, the optimal Sprint length is 1–2 weeks.

Each Sprint consists of five consecutive events: Sprint Planning, Daily Scrum, development, Sprint Review and Sprint Retrospective. All five events are mandatory for execution and time-limited.

Sprint Planning

Sprint planning is a meeting where the Scrum Team defines the Sprint Goal and discusses specific steps to achieve it.

How long: up to 8 hours if the Sprint lasts for 1 month.

Who takes part: the Product Owner, the Scrum-master, the Development Team.

Why is necessary: specifies what goals will be achieved during the Sprint.

Result: The Team has formulated the Goal of the Sprint, composed the Sprint Backlog, discussed and taken to work a few items from the Product Backlog.

Somewhere in Bollywood they shoot the series on Scrum. Before shooting the next episode, the Director and film crew discuss the upcoming work. The Director wants to make a scene in Empire State Building with mass dance flashmob. The Team estimates the time to prepare decorations and train the crowd and says they did not have enough time. As a result, the flashmob is refused. The main character will dance alone in the lobby of the hotel, which is very similar to Empire State Building. The team wrote down what needed to be done.

Daily Scrum

Daily Scrum is a 15-minute meeting where the Development Team assesses how the work is progressing and synchronizes plans for the next 24 hours.

How long: 15 minutes.

Who takes part: The Development Team. The Scrum-master may present but does not interfere in the discussion.

Why is necessary: sync, assess the progress, identify the problems.

Result: Each Team member understands how the Team moves towards the Sprint Goal and what contribution he will do today to the achievement of a common goal.

At sunrise, the crew discusses the upcoming day. Mike agreed to shoot in the hotel, Peter-about transport. Costume designer Jannifer reported that there is no dance suit for the main character. They talked about the plan for today: to find where to rent a suit, to prepare the shooting area, to cast actors for occasional roles.

Development

The development is called the Development Team workflow process during one Sprint.

How long: from 5 till 20 days, depends on the Sprint length.

Who takes part: the Product Owner, the Scrum-master, the Development Team.

Why is necessary: During development the Team creates or improves the Product.

Result: Product increment-a new part of the Product, ready to be shown and valuable for the customer.

It takes a week to shoot one episode. During it the crew changes locations, practices in dances, modifies the scenario, shoots, views ready content and edits together. On Monday, a new episode is ready.

Sprint Review

This is unofficial meeting where the Product Increment is shown to Stakeholders. All can touch and check it, discuss what is missing, what to change or add.

How long: up to 8 hours if the Sprint lasts for 1 month.

Who takes part: the Product Owner, the Scrum-master, the Development Team, stakeholders, customers, company’s other teams members.

Why is necessary: to collect feedback, demonstrate Product improvements, receive comments, determine the future direction of work.

Result: The Product Owner has updated the Product Backlog, got feedback, the Team finished the job and ready to work on.

Before going on TV the Team shows a new episode in the Studio. Team members invite their families, sponsor of the series also arrives. After watching all discuss the new episode and misadventures of the main character drinking a cup of tea with sweets.

Sprint Retrospective

Meeting of the Scrum-master and the Development Team, where they discuss the work of the Team. What problems in relationships, tools and processes the Team faced and how they can be fixed.

How long: up to 3 hours if the Sprint lasts for 1 month.

Who takes part: the Scrum-master, the Development Team.

Why is necessary: to constantly improve the workflow process of the Team.

Result: The Team discussed what prevented their work, made a plan how to fix the problems.

After watching and discussing the episode, the film crew gathered on the terrace to discuss how the week has passed by and to resolve the impending conflict between actors and costume designers. Actors do not like to wear the old costumes and costume designers say they have no time to sew a new ones. Decided not to sew the costumes by themselves, but to rent. Discuss the results of this decision on next Retrospective.

The consistent pass of all five Sprint events allows you to work effectively and constantly improve the Product and workflow process, depending on the customer desires and the development of technology.

It is useful to keep the Sprint duration unchanged throughout the development process so that participants can work at the certain speed. The new sprint starts immediately after the previous one comes to an end.

In extraordinary circumstances, the Product Owner can cancel the Sprint. For example, if the idea was implemented by another company or management resold the company to someone who does not want to work on Scrum. Cancellation is an unpleasant event that hurts the whole Team and negates a lot of work. Try to use it as the last resort only!

Prompts

Remember

• The sprint is a period of time that the Scrum Team creates a valuable part of the Product that is ready to be shown to the customer.
• Each Sprint consists of five consecutive events: Sprint Planning, Daily Scrum, development, Sprint Review and Sprint Retrospective.

Original text:

http://www.agilebasics.ru/sprint/

Got an idea or a project? Hire the Agile Software development team. No-Risk

Work with the best agile design and development teams.

Hire the team — get first delivery in 2 weeks.

What is the Sprint in Scrum was originally published in Eulerr on Medium, where people are continuing the conversation by highlighting and responding to this story.