The Business Value-Oriented Principles©
(BVOP^™)

Scrum is a framework

Scrum is a framework in which people should be able to deal with complex problems while delivering products of the highest possible value, productively and creatively.

Scrum is not a methodology

Scrum is not a methodology. It is not a project management practice or system. It does not provide specific guidance or methods to respond to the situation you are facing. Scrum is not a model that receives all the achievements and certainly does not guarantee any success for your products or projects.

This is the basic concept and idea of Scrum. No system or methodology can guarantee you success in any way.

Scrum is a framework made up of roles, events, and artifacts

Scrum is a framework made up of roles, events, and artifacts. It does not guide specific procedures and strategies on how to accomplish your task, or how to perform Scrum in your teams and organization.

Scrum means more independence

Scrum gives you the independence to determine the methods that meet your specific needs.

As a framework, the benefit of Scrum is that it allows for unique and autonomous thinking. Project management methodologies, which have a mandatory set of predefined rules, in theory, do not allow creativity and autonomy.

Another claim is that Scrum helps organizations deal with complex issues. This claim is just a statement because success depends on your experience, the experience of teams, and the support of senior management.

Scrum, in theory, is designed for projects where new requirements related to your work are constantly emerging.

Scrum is designed to create products using flexible models that solve adaptive problems.

What are a non-adaptive problem and a non-flexible work model?

You build a building, for example. You are in the middle of the project, and suddenly the basements flood. To solve the problem, you can only use pumps for water drainage and invest more money and time.

Non-adaptive and inflexible models are, for example, legally binding. Another example is a close contractual relationship for projects such as integrating banking software, where you have neither the freedom of creativity nor the ability to make decisions independently when problems arise. Each activity is performed step by step, according to a specific plan in the contract. A popular term for these situations in project management is the word "waterfall". The waterfall pattern is a similarity to the falling water on the stones step by step, from its beginning to its end.

What are an adaptive problem and a flexible work model?

You create a completely innovative virtual reality platform. After six months, markets and users change. Users change, and new competitors emerge. Technologies evolve. This problem needs to be solved. The only way is to act according to your abilities, intuition, competence, and skills. You subsequently change your product, your technology, while simultaneously, research customers. You adapt to change. The popular term for a flexible working model is Agile.

Scrum requires regular inspections

Scrum requires regular work quality and results inspections. Inspection is performed daily and weekly, for example, which helps the team quickly identify obstacles and synchronize their efforts to overcome them. An adaptation then follows the inspection. This adaptability to changing requirements is key to achieving higher value.

Scrum is created with roles, events, artifacts, and rules with the mission of delivering the most value to the end-user in the present events. The purpose of time-limited iteration at Scrum is to provide value in the form of a potentially incrementing product that can be delivered. This term is known as “potentially releasable product increment”.

The success of an iteration is measured by the amount of value provided. The more value, the more success.

Let’s summarize

For beginners, terminology in Scrum is often incomprehensible and confusing. But one day, newcomers realize that ideas are not as scary as they sound.

The entire official Scrum Guide is 19 pages long. This means that Scrum gives you freedom. From these 19 pages of the guide, you have to create products that often cost millions. With that, we want to tell you that success will depend heavily on you.

For comparison, project management textbooks and guides are between 300 and 600 pages. Project management also cannot guarantee you success because achieving success by following any project management methodology also depends entirely on you, your teams, and everyone in the organization.

Scrum roles are your “positions” or what you do in your job: developer, Scrum Master, Product Owner.

A developer in Scrum can be a professional from different positions such as programmers, QA specialists, business analysts, technical documentation creators. Anyone who is not a Scrum Master or Product Owner is part of the so-called Development Team.

Events are defined as meetings. Those meetings can be between the team’s members only or can include other parties involved in the business. During the events, the completed work is demonstrated, or work processes are discussed.

The artifacts are your planned or completed “tasks”, the conditions they possess, scoreboards, and more.

The increment, in real terms, is what your customers want to see at the end of the week, month, etc. Increment refers to the work completed in the most recent period.

Rules are rules. For example, a meeting cannot be more than a certain number of minutes. Another rule is that your team cannot be more than 9 people. During a meeting, a role representative may be absent or may be present, but in no way engaging in the conversations.

An iteration is just one period - for example, two weeks during which you work.

The success of iteration and its value is again something simple. During your period of work, you should have completed tasks that are important to your client. For example, the product already has more functionalities, or you have fixed essential bugs.

A simple understanding of Agile is a type of software development approach that is explained in the four Agile manifesto values ​​and principles. The "Agile Manifesto" states:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

People and relationships are more important than processes and tools.

This means that people’s personal qualities and their interactions are much more critical to your success. This is the opposite of project management methodologies where it is not the people that matter but the processes, documents, and tools.

Running software is more important than complex documentation.

Agile manifesto authors want to say that it is more important for the software you are developing to work better than spending months writing documentation.

Customer involvement in product development is more important than contractual relationships.

This means that it is better for you to get along well with your clients, to understand their dynamically changing requirements, and to make the necessary changes than to rely on contracts and legal relationships.

The Agile approach promotes repetitive, growing, and highly adaptable workflows

The Agile approach promotes repetitive, growing, and highly adaptable workflows that lead to the delivery of a functioning product as soon as possible after the start of the project (within weeks, not months). The Agile approach encourages teams to find ways to become more productive and then test them in practice. Also, Agile requires high levels of collaboration between self-organizing cross-teams.

Responding to change is more important than following the initial plan. Agile thinking means that people are aware of the many changing factors during product development.

BVOP focuses on the following significant Agile principles:

The highest priority is customer satisfaction through early and continuously phased delivery of a high-value customer product.

Changing requirements are welcomed and not seen as troublesome or inconvenient, even if the change is in the final stages of the project.

Businesses and developers need to work together and help each other on a daily basis.

Products should be created by motivated people who are given freedom of expression and the right environment.

The most effective method of transmitting information is a face-to-face conversation.

A working product is a substantial measure of progress.

Sustainable development is encouraged. Sponsors, developers, and users must be able to maintain a steady pace as the project progresses.

Continuous attention to technical excellence and good design increase flexibility.

Teams must focus primarily on the work that is currently being done. Many started tasks are not recommended.

At regular intervals, the team gathers and discusses how to become more productive and adjust their actions appropriately.

Teams need to be self-organizing, responsible, and disciplined because, in Agile principles, this is the most crucial element to success.

Scrum and changes

Scrum often requires many changes, including attitudes and culture. To effectively implement Scrum, it is not enough to simply accept the structure it offers but to truly understand the flexible principles and apply them consistently as a team.

Scrum can help you respond more effectively to rapid changes in the environment, market, consumers and businesses. It is designed to provide predictability of events, if you are monitoring change and to control risk.

Scrum helps you organize your work

Scrum helps you organize your work so that you deliver something valuable to every customer. This “something valuable” is called “Potentially Shippable Product Increment”.

Scrum and stakeholder feedback

Scrum allows you to gather stakeholder feedback at the end of each iteration. Based on this feedback, you can further customize your processes and product and increase their value. If market demands change, Scrum allows you to adapt faster. In this way, it helps you reduce risk.

Once a team has started using Scrum, over time, they begin to discover problems with their current workflow. Problem study may be possible if efforts are made to monitor the process adequately and discuss the issues. It can also become clearer what teams need to improve their work and ensure that they achieve their goal.

Application of the Three Pillars of Scrum

The three Pillars of Scrum are applied for productive improvement. They are:

• Transparency
• Inspection
• Adaptation

The Scrum workflow is transparent, making it easy for participants to inspect their current status, identify problems, and adapt accordingly.

Transparency

Transparency allows the team to inspect their work and progress and adapt when they see room for improvement. The entire Scrum team and the organization as a whole are involved in a continuous improvement cycle.

Transparency is achieved through:

• Consistent inspection and adaptation of events (Daily Scrum meetings for review and retrospectives) that encourage team members to overcome the obstacles they face.
• Transparent, clear, and understandable Product Backlog tasks, visible and easily accessible to all.
• A shared understanding of Scrum concepts.

BVOP states that transparency, in theory, is of great help to complete work and processes, but in practice, there may be problems with it. Not everyone prefers to be transparent. Not every director will prefer transparent processes where issues are discussed and brought to light.

Inspection

The Scrum team checks the artifacts it creates and their progress toward the main goal. Verification is performed throughout the Sprint. If a Scrum team member has any concerns and encounters any obstacles, those concerns are shared with other team members. Sharing occurs during the Daily Scrum meeting, the Retrospective meeting, or during the Sprint Review meeting. BVOP states that sharing problems can happen at any other time without waiting for specific events if this does not interfere with the team in any way.

The official term for these meetings is "events".

The Scrum Team consists of all product developers, Scrum Master, and Product Owner.

Adaptation

When obstacles arise as a result of inspections, the Scrum team adjusts how they work to remove them. These can be situations where the Scrum process is compromised or can be improved in some aspects.

Another problem may be, for example, that the team is not progressing as expected, or the work of the team is not increasing the business value of the product, etc.

Scrum requires the removal of these obstacles as soon as possible, but it is up to the team to determine exactly how to do it. Developers, Scrum Master, and Product Owner work together to solve their problems.

Outsiders such as clients or senior management should not make decisions instead of the team.

However, in real life, this may not always be the case. Some individuals outside the Scrum Team may wish to manage their jobs, tasks, and even people.

Another possible downside to the Scrum principles is when one of the team members assumes he or she is a leader.

Empiricism

A popular term in Scrum is empiricism.

Empiricism is simply a practice through which decisions are made based on real experiences and real situations. This means that when decisions are made in unforeseen circumstances or when complex problems are solved, the basis of the action or decisions is known and proven, not observed or felt.

Ideas are tested through experimentation and then noted, rejected, or changed to something better or more valuable.

Empirical practices

Empirical practices are used in Scrum to ensure continuous improvement of workflows and real results. Scrum allows continuous improvement through its events (Daily Scrum, Retrospective, and Sprint Review). These events are inspection and adaptation opportunities that take place at regular intervals.

The inspection gives the team information about what they are doing well and what areas of their work can be improved. The goal of continuous improvement of Scrum is to provide higher value to end-users.

Scrum’s rules and ideas cannot help the team and the organization by itself. Тeam members' experience and the ability to improve and develop all Scrum roles are the main criteria for success. Another essential factor for the significant development of the organization, teams, and products is the deep understanding of Scrum processes and culture from all key roles. The organization should not interfere in any negative way.

Most significant obstacles for Scrum

BVOP states that the most significant obstacle for Scrum is the inexperience of the organization and its teams.

Possible reasons for an organization not to use Scrum purposefully could be:

• Senior management's fear of using Agile methodologies.
• Weak control over teams and avoidance of micromanagement.
• Unawareness of Scrum's ideas, principles, rules, and goals.
• Lack of enough competent Scrum roles and teams.
• The objection of external stakeholders to use Scrum.
• A previous negative experience of the organization with the use of Scrum.

Possible reasons for an organization to use Scrum could be:

• All popular Scrum ideas and applications.
• Scrum's popularity to attract competent staff.
• The popularity of Scrum to attract customers and partners.
• The explicit desire to use Scrum by customers or partners.
• Using Scrum in other teams on which the organization depends.

Kaizen includes all aspects of organizations and all their participants. This philosophy aims to eliminate waste and deliver even more high-quality practices.

Empirically, Kaizen involves performing small experiments and then monitoring the results and making appropriate adjustments. Kaizen proposes doing this all the time when it is applicable.

The Kaizen cycle

The Kaizen cycle can be defined as: "Plan → Do → Check → Act". This is also known as the Shewhart or PDCA cycle.

Another technique used in conjunction with the PDCA is the "Five Whys". This is a form of root cause analysis in which the user asks a series of five "why" questions in the event of failure, where each follow-up question is based on the previously given answer.

There are usually several reasons for one root cause of failure, and they can be identified. The five whys can be used as a foundational tool in personal or work relations, as well as in technical and production matters.

One important point to note is that the five whys can reveal a problem long before the fifth one is asked.

Here are a few examples:

Issue:

"System users don't use the option to export files, which looks like a serious anomaly."

"Why" first asked:

We noticed that the export module has low user traffic.

"Why," asked for the second time:

We conducted a test and found that the file export module is not easily visible in the user interface.

Asking the question "Why" in this case identified the problem as early as the second question.

Here is another example:

Issue:

"My team members are avoiding me and not communicating with me as much as I’d like."

Why First Time?

"I guess they don't like me."

Why the Second Time?

"They may be scared of me."

Why the Third Time?

"I once told them that if they delayed the project, I would report them to management and fire them."

A clear solution is already being observed.

Kaizen and the 20 Keys to Workplace Improvement

In the 1990s, Professor Iwao Kobayashi published his book 20 Keys to Workplace Improvement and created a practical framework for improvement called 20 Keys. At that time, 20 areas were identified that needed to be improved to achieve a complete and sustainable change.

These are:

1. Clean and tidy up. Everywhere and all the time.

2. Management style with engagement and participation. Work with all people to engage their minds, hearts, and hands in the work.

3. Teamwork. Focus on collaboration to get everyone involved in enthusiastic improvements.

4. Reduced inventory and lead time. Dealing with overproduction and reducing costs and time.

5. Changeover reduction. Reducing the time for changing dies (a device for cutting or moulding metal into a particular shape) and machines to achieve a more flexible operation.

Logically, in processes that do not involve machines and tools, you can focus on reducing the technological time for your operations.

6. Continuous improvement of the workplace. Generating growth as a way of life, continually improving work, and better jobs.

7. Zero monitoring. Build systems that avoid the need for human control on an ongoing basis. Instead, create a team that works to maintain and improve your technology.

8. Creating interconnected cells where flow and pull are the order of the day.

We can follow this idea by understanding that related processes throughout production must follow an order and not be hindered. Results throughout the day and at the end of the day are essential.

9. Maintenance. Maintenance of machines by people who work with them, not by external specialists. This allows for constant adjustment and minimal downtime.

Interpret this as the idea that you have to maintain your systems and products yourself, not an outside company. You are most familiar with your products and technology.

10. Disciplined, rhythmic work. Synchronized systems where all parts work together.

11. Defects. Defect management, including defective parts and connections.

Monitor, control, and manage your defects. Look for reasons and strive to avoid them.

12. Supplier partnerships. Working with suppliers which makes them part of an ever-improving chain instead of struggling with them.

13. Waste. Constantly identifying and eliminating things that either don't add value or even destroy it.

These can be processes, ways of working, even roles or positions. Anything that doesn't help you should be removed from your job.

14. Employee support and training. Training employees to work at a higher level so that they can increase the value they add to the work.

15. Cross-Functioning. Employees work with colleagues from different departments and even change departments to gain experience in other areas.

16. Scheduling. Operation times are planned to create a flow of high quality and affordable products.

17. Efficiency. Balancing financial problems with other areas that indirectly affect costs.

18. Technology. Training people to use innovative technology so they can adapt to it, providing the latest technologies and making them useful in real environments.

19. Conservation. Saving resources to avoid waste for the company, the community and the environment.

20. Site technology and Concurrent Engineering. Understanding and using methods such as concurrent engineering and Taguchi methods.

Kanban is a Just in Time (JIT) production planning system. Taiichi Ohno, a Toyota industrial engineer, developed Kanban to improve production efficiency. It is one of the methods of achieving JIT.

Kanban is perceived as a useful tool for maintaining the manufacturing system as a whole, and a great way to encourage improvement. Problem areas are highlighted by measuring execution time and cycle time of overall process steps. One of the main advantages of Kanban is to set a maximum limit for work that is in the process of being created and completed (Work in Progress).

The purpose of the Kanban system

The purpose of the Kanban system is to limit the accumulation of surplus stocks at each point of production. Exceeding a limit means inefficiencies that must be resolved by teams and management.

In software engineering, Kanban is used to limit the work in progress. These limitations aim to reduce the number of defects and the stress on teams and increase their focus. By introducing work limitations and minimizing obstacles, overall productivity should increase.

Kanban is an Agile style of working

Kanban is a popular Agile working style used in software development. Kanban requires team capacity communication in real-time and full transparency of work. The tasks of the teams are visually presented on a Kanban board, which allows the team members to see the status of work at any time.

The Kanban Board

The Kanban Dashboard, or Board, is an Agile project management tool designed to visualize work, limit Work in Progress, and increase efficiency. Kanban boards use cards and columns to help teams engage with the right amount of work.

What is a card?

The "card" is a visualization of the "task" (the effort it takes to get the job done). It may contain the name of the work required (effort), a description, and other elements such as the "type" of the effort.

What is a column?

The "column" is a very simple visual vertical column containing cards.

Each column should contain cards but in a limited amount.

Tasks in progress (Column 1)	Tasks in a testing (Column 2)	Waiting for approval (Column 3)
Task 1	Task 2	Task 7
Task 3	Task 4
Task 5	Task 6

In the example table above, the logic stated is as follows:

The first column 1 lists the cards (work, tasks, efforts) that are currently being developed.

In the second column, some cards (tasks) are already completed but expect quality control specialists to confirm that there are no problems with them.

The third column contains the cards, which are tested for defects and are awaiting approval from someone.

These columns are just an example. The team invents their names, determines the number of cards and columns that the Kanban dashboard will have.

Each column represents some logical steps in the workflow.

There can be four, five, or even more columns in the dashboard if each task has to go through every stage that the team has defined.

It is logical that the more steps there are in the process, the more complex is the team workflow. An optimal workflow requires a balance between performance and simplicity.

Work In Progress.

These are the cards that are currently being developed.

Kanban puts a limit on the workflow by simply restricting the number of cards that can be stacked in a single column. If a wooden board on which notes are attached for each task is used, the column cannot be infinitely high. Also, the whole team should know how many cards (tasks) are allowed in one column.

If Kanban Board software is used, the software itself may limit the number of cards.

The teams decide for themselves how many cards (tasks) are in the columns, based on the amount of work that can be done.

The teams decide whether to use the Kanban method of work. It will be a mistake if such a decision is made by senior management, especially if there is no in-depth knowledge of ​​the day-to-day work of the teams, their processes, needs, problems, competence, weaknesses, and strengths.

The same goes for using Scrum. Teams discuss how and most of all, why to use it. It will be practical to experiment and go through different ways of working in order to decide which one is best. Sometimes a working method will no longer be helpful, and decisions can be made to change it.

Work in progress includes not only the currently executed tasks but these for testing and approval.

In Scrum, Agile, and all other work methods, this idea must be kept in mind.

When a card is completely finished, it must be removed from the dashboard and if necessary a new one added in its place.

Scrum Board

When working with Scrum, the board usually has no limit on the number of tasks. The team plans the number of "cards" (items, tasks) during the Sprint Planning meeting.

Whether working with Scrum or Kanban, teams must regularly check performance. Do the teams handle the planned tasks? Are there too many, too few cards to place, or is workload precision achieved?

Validation and change are at the heart of the whole Agile culture.

The main differences between Scrum and Kanban

Scrum has sprints and roles (Scrum Master, Product Owner, and Development team).

There are no sprints or roles at Kanban.

In both cases, the teams are self-organizing.

The Kanban board is used continuously throughout the product development lifecycle by simply replacing the cards.

At Scrum, at the end of each sprint, the dashboard is renewed. No new cards (items) are added until the end of the sprint. Cards are also often found in columns and have a corresponding status.

Kanban or Scrum

When it comes to Agile practices, some organizations explicitly use Kanban for some of their projects. Others explicitly prefer Scrum.

When an organization states out loud that it is using Kanban, this is likely due to some of the following factors that are unrelated to the Kanban practice itself:

• The organization does not have enough staff capacity, and the teams are too small.
• The organization does not have sufficient management experience.
• The organization aims to save money.
• The organization and teams practice micromanagement. These manifestations can often be generated by senior management.

Moreover, these probable causes are even more likely if the Kanban approach is practiced in organizations that do not clearly express Agile production methods or do not have a transparent Agile culture.

Kanban the right way

There is always the possibility that an organization will use Kanban for the intended purpose, and not for the aforementioned negative reasons.

Using Kanban to organize the work and help the team means a high Agile culture, as well as great discipline, self-organization, and competence.

Kanban is a flow of work that is ongoing

Kanban is a workflow in which there are no "sprints". Kanban is a flow of work that is ongoing.

Kanban may exhaust teams

BVOP focuses attention on the fact that teams can feel exhausted over time.

The lack of some periodicity and cycles can bring about the feeling of endless and unfinished work. Energy and motivation can be reduced.

Scrum offers sprints. These are equal intervals of time that can psychologically satisfy the need for a beginning and an end.

The periodicity and the end goal of a sprint can bring a sense of accomplishment and completion. Such recurrence helps for optimal mental dynamics and satisfaction with the goal achieved.

BVOP recommends that the choice between Kanban or Scrum is made after both work methods are tested. A periodic opinion review of all team members can help decide whether a migration to another style of work is necessary.

What is Lean?

Lean thinking is a business idea that aims to provide a way of thinking about organizing human activities to provide more benefits while eliminating waste.

Lean thinking comes from Toyota Motor Company, which went from being a bankrupt Japanese carmaker business in the early 1950s to becoming the dominant global manufacturer it is today. At every stage of its expansion, Toyota is targeting new markets for products that are considered relatively unattractive. The organization avoids standard practices and thus seeks to increase the value of its operations and investments.

The company has applied the practice of appointing a unique group of elders (Sensei) and coordinators (teachers from Japan), dedicated to helping the company’s managers to think differently.

Toyota’s training focuses on developing people’s thinking skills, not forcing them to perform specialized tasks, and use standard practices, tools, and procedures.

These “sensei” have caused managers to look at their jobs differently.

Some of their teachings are focused on the following topics:

You go and see the working conditions first hand and discover the facts for yourself instead of relying on reports and meetings in the boardroom.

The workplace is where real people deliver real value. It should be evident that managers support and respect their employees for adding value to the organization through their ideas and initiatives.

The imposition of the idea that customer satisfaction is paramount is embedded in every step of the company’s process. You have to stop at every problematic part, analyze it and get to the point where you and everyone in the team do not let it be the reason for a defective product and do not accept defective work. The work process stops when things go wrong.

Understanding the cycle time and creating a rhythm. This “rhythm”, whether it is for the production of automobiles or software projects, leads to the creation of stable value flows, where stable teams work on a stable set of products in stable environments and with stable processes.

Reduction in production size. Every traditional business has strong desires for a large amount of work produced. High volume production can lead to waste.

Lean thinking

Lean thinking is trying to optimize the flow of work to meet current demand, not future demand.

By reducing time and difficulty in our work, it is possible to get closer to perfect results. In this way, we can dramatically minimize the overall spendings of our business by reducing the need for additional costs for outsourcing, fees, procedures, materials, equipment, and more.

Preview work and processes through Kanban. As much as a manager or an operational officer is experienced, process failures always occur. That is why, visualizing tasks, jobs, and processes through Kanban can make apparent work issues and greatly help everyone.

The search for perfection through Kaizen.

The old Sensei argued that it was not of the highest importance to use tools and standards for each process or activity but to develop the spirit of each employee.

Perfection is not achieved through better, smarter systems or characters, but by a desire to improve performance step by step together.

Kaizen’s practice is what creates deep and reasonably productive thinking in people’s minds and ultimately leads to complete transformation. Practicing Kaizen on an organizational level increases collective and self-confidence so the organization can face more significant challenges and solve problems.

What is MVP

MVP stands for “Minimum viable product”. A minimum viable product has sufficient functionality that satisfies early adopters who provide feedback on its future development.

MVP is not rushing to do everything

When you create an MVP this means that you are more focused on the essential concepts initially instead of rushing to implement every single thing you or your managers have decided, which can affect the product negatively.

Providing feedback on MVP

Providing feedback means that when you have a minimal product, you will be able to see the reaction of your users and customers. Do they like your product? Is it useful for them or not? On this basis, you continue your research and work.

Gathering initial information about your MVP is often less expensive than developing a multi-function product, which increases the cost and risk in the event of failure.

A minimum viable product has enough basic features (or functionalities) for effective initial product launch and nothing more.

Developers usually focus on a group of potential customers - such as early adopters, who are thought to “forgive” more minor issues, are more likely to give feedback and can understand the product’s vision from its early stages.

This strategy aims to avoid creating features that customers do not want anyway.

MVP is recreated in cycles

MVP is recreated in cycles and iterations by generating ideas, prototyping, collecting data, analyzing, and learning from the results so far.

The goal is to minimize the total time spent in an iteration. The process is repeated until the desired product is obtained or until it is considered unsustainable.

Scrum is popular, but that doesn't mean it should always be used. It has advantages.

The Waterfall method is the traditional project management approach. The Waterfall is a linear and consistent procedure. This means that in this approach, you are processing one phase after another in a linear fashion and do not have any overlap in the phases.

Example:

• You cannot do the design before you have done the planning.
• You can't get started before you've done the design.
• You can't test anything before the project is ready.
• And so on.

Scrum for rapidly changing requirements

In the real modern world, many products and organizations have to cope with rapidly changing requirements, customers, users, needs.

In Waterfall, where everything is consistent, teams need to have all the requirements at the beginning of the project, and everything is documented, every step is planned, discussed, and approved by multiple stakeholders.

Each change in the project changes the documentation, budgets, and deadlines. BVOP states that this can cause stress for many teams and participants.

When following the Waterfall methodology, it is usually challenging to offer any product to the client or organization before the end of the project.

After a certain amount of time has elapsed after the project's launch, it may not meet the needs of the market.

A possible problematic situation would be if project stakeholders no longer even need what they used to a long time ago.

Waterfall project management is, in fact, excellent and stable. Tasks must be completed one after the other, and detailed planning and design are required before work on the actual project begins.

The Waterfall is very suitable for businesses such as heavy industry and construction, where the direction and scope of the project remain relatively unchanged.

Waterfall, on the other hand, may not be suitable for projects where the product needs constant adaptation to changing requirements and circumstances.

For example, if a product to be developed is a mobile application for artists or a new innovative virtual reality, Waterfall may not be the right method of operation.

One important topic in all Agile practices and Scrum is the value theme, which BVOP strongly emphasizes and generalizes to the overall Business Value idea.

For many products, value is not just a timely completion of a project, adherence to basic rules, or fit into a specific budget.

For some products, business value can be a highly usable user interface. For other products, business value will be quick work; for others, it will be readable text.

Iteration and Increment

Iterations in Scrum

Scrum is organized in cycles.

It is "iterative". It means repetitive. In Scrum, work is organized at intervals called Sprints.

Inspection and adaptation also occur iteratively within each Sprint. Scrum events (Daily Scrum, Sprint Planning, Sprint Review, and Sprint Retrospective) also take place at each iteration (repetition).

Scrum is incremental

During the iteration (also known as Sprint, or the time interval in which the team works), the team works collaboratively to create a "Potentially Shippable Product Increment".

This "increment" is a working version of the product being developed that can be made available to end-users. These increments (better versions) must be fully completed. There should be no hidden, unknown work that still needs to be done.

Inspection is performed on the “incremental” product, and any adjustments made aim to create a better and more valuable version.

What is Increment?

The simplest explanation is that increment is the current version of the product you are developing. This current version contains all the previous work put into the product, plus the one in the current sprint.

If your project just started and you are in the first sprint, your increment is only the completed work for the current (first) period.

If you are already in the second sprint, then your increment is simply the outcome of the previous sprint, plus the tasks you completed during the current sprint.

Scrum includes the following elements:

• Roles
• Events
• Artifacts
• Rules

Scrum roles

The roles are the people who participate in Scrum. They are called roles because everyone has a specific "role", does certain things, and "is responsible" for certain matters.

Scrum has three roles:

• Development team
• Product Owner
• Scrum Master

There are no other roles in Scrum. These roles do not interfere in any way with the official positions of the people in the organization.

The development team

The development team combines the developers. It only includes people who work to complete the tasks. It's rare, but developers can play the role of Product Owner or Scrum Master. This approach is not recommended.

The development team may include people of different competences, skills, and positions. These can be programmers, designers, architects, engineers, quality control, business analysts, and anyone else who actually works on the product.

The Product Owner

The Product Owner is the role that represents the voice of the stakeholders and is responsible for ensuring that the team delivers value to the business.

Stakeholders

Stakeholders can be clients, directors, consultants, employees. These are people who have some interest in the product.

The client or senior management has an interest in the product. Still, other people in the organization may also be interested if they are going to use the product in their work.

The Product Owner role prioritizes all items in the Product Backlog list by their "business value" for the product.  This role comprises high product and field knowledge, holding consultations with stakeholders, and giving individual judgment to each task or idea. The Product Owner role can informally confirm that the currently developing product will satisfy everyone, and most likely, the increment will be approved.

The Scrum Master

The most important role of the Scrum Master is to make sure that the Development team works by following the values ​​and practices of Scrum. It also seeks to create comfort, remove barriers, teaches and educates the team on productivity, self-organization, responsibility, and discipline.

Scrum Team

The Scrum Team is a generic term that includes all the Scrum Roles: Development Team, Product Owner, and Scrum Master.

When we talk about the Scrum Team, we always have in mind all the Scrum roles combined.

Scrum artifacts

Scrum artifacts are several physical elements. They are used in Scrum daily, as well as in product work generally. The Scrum team and other non-team stakeholders often pay attention to these artifacts to know how product development, activities, and everything else is progressing.

The official Scrum artifacts are:

• Product Backlog
• Sprint Backlog
• Product Increment

BVOP adds a few more essential artifacts to this list that underpin every product development:

• Sprint Goal
• Definition of Done
• Product Vision
• Burn-Down Chart

The Product Backlog

Product Backlog is a trendy term in product management, Agile environments, and Scrum framework.

Product Backlog is a whole bunch of ideas, items, and development proposals that are accumulated and compiled into a list.

The Sprint Backlog

Sprint Backlog is a work and task list that is a sample of the entire Product Backlog list.

Sprint Backlog is the "list" of "tasks" that the Development Team must complete during a specific sprint (period).

All the ideas, requests, and tasks that come in the form of a large list are called Items. Product Backlog Items are the content of the Product Backlog. They are called items because their form can be very different. Something can be written down as an idea, another as a task, third as a defect, fourth as a suggestion for improvement, fifth as a User story, sixth may be just a graph or a diagram, etc.

The Increment

The increment is the current version of the product under development. This current version contains all the previously done work on the product, plus the work done in the current Sprint.

By "work done" we mean finished Product Backlog Items from the Sprint Backlog list.

The Sprint Goal

Sprint Goal is an abstract and common goal for the current sprint. A sprint can have many "tasks" from the Sprint Backlog list, but the overall "goal" is a summary of them all.

The Sprint Goal can be defined in free text. The team decides how long the goal text is and what exactly it should contain. While reading the goal, it is crucial to understand what needs to be developed.

In real life, many Scrum teams do not record their goals. The reasons may be a lack of creativity or just unwillingness.

Definition of Done

Definition of Done is a set of criteria that must be met by all Product Backlog Items so that they can become part of a Product Increment.

These definitions can be understood as short and understandable requirements and a list of things to do. Once all these requirements and criteria are met, and everything described in them is complete, the Product Backlog Item can be considered done.

The product vision

A product vision can be understood as a "description" of the product. It contains several sections with information such as users, competitors, advantages, promotion methods, ways of distribution, etc. This information is defined at the earliest stages when the product is still just an idea. Product teams use this "vision" as a basis for creating concepts, ideas, and further.

The Burn-Down Chart

Burn-Down Chart is a simple graph that shows the finished work and the remaining time in a sprint. By finished work, we mean completed items from the backlog. Most often, this chart is valid for the current sprint only.

The purpose and application of this graph are simply a quick and easy way to view your progress on the task at a glance.

Scrum events

Scrum events are ordinary events (meetings that have a specific purpose). Certain situations arise at every event.

The official Scrum events are:

• Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

There is no hierarchy in Scrum. However, the responsibilities must be known and respected.

The Product Owner role is part of the Scrum team

The Product Owner role is part of the Scrum team, along with the Development Team and the Scrum Master role.

The Product Owner represents the stakeholders 

People can have a work schedule and work hard on every project but there is always the likelihood that they will put effort into parts that are not that important. The Product Owner role is the "stakeholders' voice" and is responsible for giving value to the work that comes from the Development team. Value, in this case, means producing an effort (work) on tasks that are of the utmost importance to the product.

The Product Owner and the User Stories

The Product Owner role creates user-oriented "tasks" (items). Items have a broad meaning and include not only User Stories but also defects (bugs), research tasks or technical improvements, ideas, etc. The most popular item format is called User Stories. These are the "tasks" that the entire team works on to create the product.

The Product Owner also prioritizes the entire User Stories list (the Product Backlog) so that the team can focus on the most valuable ones. User stories can be broken down to separate small tasks, which facilitates the team and makes tracking and control a bit easier.  User Story can be defined as a whole idea that is developed by one or a number of team members who each do their part (task or tasks).

The Product Owner role works with stakeholders and represents their interest. He or she is looking for ways to satisfy their product requirements.

Sometimes, before the actual work starts, the Product Owner and the stakeholders create the so-called Product Vision.

Product Vision

Product Vision is a collection of information divided into groups. Data is collected on the actual users of the product, their needs or expectations, ways of distribution, sales methods, and other market factors. The factors determining the price can also often be a theme in the Product Vision.

When all this information is gathered, the Product Vision serves as a basis for creating ideas, concepts, prototypes for the project, as well as its actual production.

In classic Product Management, working on the Product Vision is Product Manager activity. But since Scrum does not include a Product Manager role, the Product Owner role is the closest to Product Manager.

The Product Owner as the Scrum Product Manager

Although the Scrum Guide does not provide any details about actual product knowledge and practices, BVOP suggests that the Product Owner should have product knowledge. This role should also have knowledge of product users, the market and its features, competition, and modern trends in the industry.

The primary responsibilities of the Product Owner role can be defined as:

• Keeping an idea and vision of how the product will develop.
• Continuous cooperation and communication with stakeholders.
• Creating and maintaining a Product Backlog - writing User Stories.
• Prioritize Product Backlog.
• Release Management - Define phases and release dates for new product releases.
• Track work progress, time, and budget.

Value for products

The Product Owner must "create" a product that delivers real value to its users, customers, and stakeholders.

But what does this mean?

Consumer value can be any convenience, utility, or social or professional benefit. If the product is new storage software, then its users should expect more accurate storage details, more comfortable or faster use.

Value for stakeholders (owners, investors, partners, agents) can be measured in profit or benefit - financial gain, economic or marketing advantage.

The Product Owner and the prioritizing of the Product Backlog

The Product Owner needs to prioritize the work according to the Product Backlog and ensure that the items in it are fully prepared for the current Sprint and Increment. This means that all User Stories that the team is expected to work on during the Sprint should be clear, detailed, and understandable by everyone.

Understanding the Business

The Product Owner role as stakeholders' representative (and their needs) must fully understand the expectations of the business parties. It is a liaison between business stakeholders and the Development team. The Product Owner communicates with various business representatives, collects information on upcoming sprints, shares team progress.

When a team member encounters ambiguity in a task, the Product Owner should be there to assist and share information, details, or an alternative product solution.

The Product Owner does not relate to the way the teams do their work, does not share technical suggestions or specific technical methods of implementation.

User stories

The Product Owner "translates" stakeholders' desires and records them in the form of User Stories using an understandable language.

In the process, the Product Owner and the Scrum Master roles communicate with the Development team to ensure that they understand the user stories.

User Story is an informal and brief description of any consumer need. Usually, a User Story is a written form that represents the perspective of the potential consumer of the product regarding its functionality. User Stories are based on users who need functionality and have goals.

For clarity, let's describe what a User Story might look like. The user story follows a standard and is created using the following format:

As a (role), I need (capability), so that (receive the benefit).

(role) - The role is "who" needs something.

(capability) - the exact need

(receive the benefit) - a positive result for one who requires something (the user).

Each User Story is advised to be logically independent regardless of the others. It’s not recommended for user stories to overlap. They can be "broken down" in a way that allows the team to predict the development time easily.

It is recommended that a User Story is created in such a way that it can be completed within a Sprint. If a duration of a Sprint is one week, this means that the User Story should not take more than that to be created, tested, and accepted (approved) by stakeholders. It should allow easy testing, validation, and acceptance.

Acceptance criteria

A User Story is recommended to include an Acceptance criteria section, as it is an important part. These "acceptance criteria" contain the "conditions" that the work of the Development Team must meet.

Acceptance criteria are added to each User Story to guide testing conditions.

A User Story cannot be accepted partly for any reason. All conditions must be met. It is advisable to be cautious when stating that the work is almost done or only small things (tasks) remain.

The Product Owner can be tempted to agree to these incomplete parts or tests, which can lead to product issues and harm the business or processes.

Ending the product work

The business stakeholders can terminate any developing product at any time and completely cease the work on it. In Waterfall project management understanding, such a situation is considered negative and often leads to high levels of stress.

A very likely reason for this suspension of work may be spending more resources than planned or some other drastic change in the business.

If the Scrum team is shut down, this should not be considered a negative event. It is highly probable that the work is ceased because the business is satisfied with the product created so far.

Let's include the topic of prioritization now.

Let's say we have 500 Product Backlog Items. Most of them are User Stories. A large number of them describe important functionalities and product ideas. Others contain ideas for developing functionalities that can be seen as secondary. And the third may be trivial ideas that are recorded in the Product Backlog at the explicit request of the stakeholders.

With a list of 500 development proposals, many are unlikely to have high product value. The functionality of many of those items may not be valuable to the product.

If 300 User Stories have already been developed, starting with the most important ideas, the stakeholders may already be satisfied and do not see the need to continue working on insignificant ideas.

Therefore, the primary responsibility of the Product Owner role is to prioritize the content of the Product Backlog regularly, based on a number of factors.

Of all the prioritized Product Backlog Items, the Development Team decides how many tasks it can develop during a Sprint. Logically, during the Sprint, the team works on the User Stories, which are listed at the top of the Product Backlog. These stories become part of the Sprint Backlog list.

Release management

To easily discuss the issue of Release Management, let's clarify what Release is.

The release is understood as releasing or providing completed work. Project Managers, Product Managers, Product Owners, and other roles from different methodologies, often use this term.

A release may mean a finished part of a product or a specific version that has been modified or made more advanced than previous ones.

A release can also be used as a phase or a period. For example:

"In Release 2, we are completing user registration. In Release 3, we need to fix any registration defects."

Stakeholders, the Product Owner, and possibly the technical team members discuss what will be achieved for the next release. The Scrum Master role can also be involved in planning and discussions. It is a role that protects teams, and takes care of processes and the best practices at the same time. Discussions and arrangements should take into account both the wishes of stakeholders, their needs and expectations, as well as the capabilities and capacity of the Development Team.

Strategy and goals are created. Steps for releasing the release can be described. The specific tasks to be worked on are also often indicated in the planning of a release.

The Development team at Scrum has between 3 and 9 developers in total. The Scrum Master and Product Owner roles are not included.

If the team has one Scrum Master, one Product Owner, and a Development team of three, the entire Scrum Team is made up of 5 participants in total.

If the Scrum Master and the Product Owner are not part of the Development Team, then the entire Scrum Team will be 11 people total.

If the Scrum Master and the Product Owner take two roles and they are also developers, then the entire Scrum team will be 9 people.

Reasons for limiting the Development Team

The reason behind the suggested limit is that fewer participants will make it challenging to develop a product, and any more would create difficulties complying with the rules and principles of Scrum.

Development Team and its physical location

The main idea for small teams is to achieve self-organization and quick communication in the workplace.

However, these desired effects cannot be guaranteed. The Scrum Master role, as well as the entire Scrum team, must strive for speed and efficiency.

Globally, many organizations use remote teams and Scrum practices at the same time. This can diminish the effectiveness of communication and interaction between teams. 

The Development Team in Scrum is self-organized and cross-functional

The main features of the Scrum Development team are self-organization and cross-functionality.

Self-organization

What does self-organization mean when talking about the team? It means that Scrum represents the idea that every member of the team should be active and make their own decisions instead of waiting for orders from management roles.

Scrum does not by itself provide clear instructions about self-organization, but it can be expressed in individual decisions as well as group ones. Time optimization, self-monitoring, workflows, and many other topics can all be taken into account.

Trust among team members is another factor that can increase the productivity of a team.

Competence is another important factor. If a team member has difficulty, then he or she should try to acquire additional skills, or work together with the team to do so.

The Scrum Master role has a significant influence on the self-organization of the team. Guidance, encouragement, and giving attention to all these topics may be required to keep the team focused on their goals.

Indications for a self-organizing Development Team

The main indications that a team can be defined as self-organizing can be the following:

• The team does not have a specific person who makes decisions for everyone or orders others.
• The whole team takes responsibility for the work that is done.
• The team and its members choose their tasks themselves, without anyone else assigning them.
• There should be no situation where Scrum Master, Product Owner, or some team leader assigns tasks.
• All decisions and all teamwork are focused on achieving the Sprint goal.
• The entire team and all members estimate the time required to develop tasks.
• The team provides the work itself.
• The whole team keeps track of their progress and tries to go according to plan.
• The team inspects its work and makes the necessary improvements.

Cross-functionality

Cross-functionality means that all team members and all their general skills are entirely sufficient for the development of the whole product without the need for severe external intervention.

For example, if the product being developed is a mobile application, then at a minimum the Development team should probably include the following specialists:

• Developer, Mobile Technology (Mobile Development)
• User Interface Designer (UI Design)
• Quality Control Specialist (QA)
• System Support and Development Operations Specialist (DevOps)

In such a composition, the team probably can produce the product.

If the Development team consists of the minimum eligible Scrum participants - 3 participants - then they appear to be insufficient for the development of the product.

If the complete skill set of the team is less than the total skills and qualifications required to create the product, the most common practice and the most logical step would be to form a team of professionals who have more than one professional skill.

To develop a mobile application with a team of three participants, if four areas of qualification are required, one team member must have more than one qualification.

The Mobile Developer from the example above may have competencies to handle tasks such as servicing App Store operations, server setup, Cloud Spaces, or anything else that may need to be completed in order to deliver a fully operational mobile application, downloadable and installable.

Another option might be if the designer, for example, has all the skills and competence to handle all the QA work.

Responsibilities of the Development Team

• Creates the so-called Product Increment - product update and enhancement.
• Shares responsibility for creating a quality product, along with the Product Owner role.
• Shares estimated time to complete their tasks.
• Follows all Scrum rules and principles.

The entire Scrum team spends its time working on the Product Increment and working on the planned User Stories until each User Story is ready and evaluated (for example, with Ready status).

Resolving problems

When a member of the team is experiencing difficulties, or there is some obstacle to his/her work, he/she must notify the Scrum Master role.

The Scrum Master role should try to resolve the problem of the team member as quickly as possible.

If a person outside the team interferes with the work of a team member, for example, by contacting them or preventing them from performing their duties, the Scrum Master should be involved in the situation.

All members of the Development Team should try to remove their obstacles on their own, as they must develop skills in organizing and solving problems.

The Development Team needs to be protected

The Scrum Master role protects the team from outside interference like distracting and disturbing factors.

If a member of another team or a business stakeholder wants something, the Scrum Master role must be involved and act appropriately and reasonably. If the situation is fragile, the Scrum Master role offers assistance and explains that they will look into the case, and that the team should remain focused on their responsibilities.

If external intervention involves a work request that needs to be done, the Scrum Master role seeks assistance from the Product Owner role who needs to take action. The Product Owner will, at its discretion, decide to add or ignore this request for new development to the Product Backlog list.

The Development Team must be united

Sharing product quality responsibility may not simply mean that the Development team adheres to the requirements and specifications of their tasks. The Development Team must be united in its practice, its processes, and in finding the right development tools and tests. A certain dose of product care would be a perfect addition to the quality of the product.

It is appropriate for the Development team to choose their working technologies and tools without outsiders requiring specific ones. This freedom of choice allows the Development Team to pick tools and technologies that can achieve better results than those imposed by outsiders.

The Development team is most knowledgeable about technology and expertise

The Development team is most knowledgeable about their skills, technology, level of competence. The team is used to specific tools. When it uses resources with which it has previous experience, the confidence of everyone is greater. Confidence can be a factor in increasing the overall quality of the product and reducing possible errors and defects.

The Development team is welcome to refuse work

The Development team is welcome to refuse to work on a particular User Story during a Sprint if some of the team members are convinced that there is something wrong with the specific User Story. In this case, the team members should discuss their concerns with the Product Owner role.

Possible irregularities in a planned User Story could be, for example, unclear or incomplete requirements, fulfillment failure, or any other aspects that would harm the product as a whole.

In this case, the Product Owner role must accept these comments, understand them, and take the necessary steps to improve or change the planned work (the User Story).

Estimating the development time required to complete a User Story

One essential part of the Development Team’s work is to determine the estimated development time of the User Stories planned for a Sprint. This defines the amount of work they can do for an iteration (Sprint).

The team anticipates the necessary effort to fully complete the work required based on their experience, knowledge, practice, skills, as well as previously done work in the last Sprint.

Relative time

There are two types of development time estimations. The first one is the accurate time to complete tasks — for example, one day or 4 hours. However, Agile practices recommend the use of relative values. The Development Team suggests time only as a guideline, not with accuracy. It is assumed that when estimating the required time for tasks, team members still have no idea how exactly they will perform their work and may lack specific details.

The fixed and always equal length of the Sprint provides the Development team with a measure of their finished work. Also, for future Sprints, estimating the amount of work becomes easier.

Supporting the Scrum Process

Each team member has the responsibility to follow and respect the Scrum process and to ensure that the other members of the team do the same. This is a core responsibility of the Scrum Мaster role, but the entire Scrum team should also support Scrum practices to some extent.

Everyone participating in Scrum events does not miss them or ignore them and is aware of their importance.

Development team members always have an idea of ​​what other team members are doing. The development team maintains the highest level of transparency and does not hide problems.

The technical knowledge and specifics of working on the product are shared with everyone. In this way, if a member leaves the team, the loss will be easier to recover.

Pair programming

Pair programming is another practice that is sometimes used by Agile teams when working on a technology or software product. Generally speaking, it is programming work, or any other kind of technical work, in which a senior and a beginner team member work together on a single task, from one computer, or another work tool.

Pair programming makes it easier for beginners to get into the matter quickly and easily, and everyone has shared knowledge of specific technical topics.

Scrum is a style of work that strives to maintain sustainable productivity for teams. Problems can quickly arise if the roles within the team and organization are not clearly defined and understood, and the team members do not follow the goals and purposes of the roles.

The Product Owner role represents the voice of consumers and the desires of stakeholders and businesses. The development team develops all these needs qualitatively.

The need for a Scrum Master role

Throughout this process, there is a need for a role that takes care of all parties and strives to comply with Scrum's rules and principles. Otherwise, chaos, micro-management, and disruption to the teams would emerge. Such negative situations can lead to a decline in motivation, defects in the product, difficult product maintenance, divergence of plans, and potential failure.

The Scrum Master role ensures that all possible negative results do not happen.

The Scrum Master strives for teams to work according to the principles and practices of Scrum.

The Scrum Master role, like all other roles in Scrum, has no authority to manage people, work, or anything. However, it has authority over everything related to Scrum processes, events, rules, ideas.

The Scrum Master acts as a leader for the team, not as a manager. Leads the team toward their goals.

The successful Scrum Master

The successful Scrum Master is committed and focused on the development of others and of the organization’s Scrum culture.

Key responsibilities of the Scrum Master role

Key responsibilities of the Scrum Master role include:

• Monitoring and eliminating obstacles in the workflow.
• Protecting the team from unwanted outside interference.
• Assistance with meetings and Scrum events.
• Collaboration with the Product Owner role.
• Coaching and guidance of all product stakeholders (Scrum team and business stakeholders) on Scrum practices and concepts.

The Scrum Master must be able to represent the significance of Scrum clearly and without complex and disturbing terminology.

Scrum Master role as a servant leader

A servant leader is a popular term used to describe the Scrum Master in two words. The traditional style of leadership is usually understood as the expression of power by one person. The understanding of the serving leader is the opposite. The needs of others are first and foremost. Teams are being helped to do their jobs well and grow.

The highest priority for the Scrum Master role is to encourage and assist the Development team in maximizing their potential and productivity, in developing their skills, and in increasing the value they create.

Collaboration with the Development Team

Protection of the team

The Scrum Master role acts as a buffer between the team and all external influences, problems, and processes.

The Scrum Master protects the Development team from the Product Owner

BVOP brings a further understanding of the team’s protection from external stakeholders. It introduces the protection of the team from the Product Owner role. The Product Owner role is part of the Scrum team, therefore it is assumed that he or she knows and fully understands the principles and rules of Scrum. However, this is not always the case. Product Owner roles in different teams and organizations can have different interests, work styles, and can be driven by certain actions depending on many factors.

The Scrum Master protects the Development team from the Development team

BVOP focuses on the important topic regarding the protection of the Development Team from its members.

Sometimes team participants may wish to manage their colleagues. In the classic management method in organizations, this would not be a problem and is even considered a positive situation.

According to Scrum rules, such management should not be accepted. Respect and equality should motivate team members and develop their creativity. Team leaders can often naturally lead to micro-management, individual decision making, assignment, and all Scrum principles will gradually be broken.

The Scrum Master role should be aware of such possible and potential violations of the Scrum rules. He or she should have a clear mind, insight, and the skills to evaluate any possible situation.

Organizing meetings

Scrum teaches that the Scrum Master role supports the team. However, there are no clear rules as to who organizes team meetings. We want to focus on the fact that a very appropriate role for this is the Scrum Master role.

Only if the team needs it, the Scrum Master role organizes meetings and events and invites everyone who needs to attend. He or she shares instructions, prepares attendees for meetings, explains discussion topics, and reminds of the Scrum rules.

If teams are disorganized and chaotic, the Scrum Master role restores order. For example, if a Product Owner role avoids an important meeting or provision of information, their presence and assistance needs to be sought.

The Scrum Master is a Coach

Coaching is not just about the rules and principles of Scrum. The motivation, ambition, and focus of the team must be maintained.

Some team members may not understand the terminology or practices used by the rest of the team. The Scrum Master role helps everyone around to get into Scrum's atmosphere and ideas.

Removing obstacles and problems

Every team, project, and organization has problems and obstacles of many kinds that can arise at any time.

The Scrum Master is actively working to resolve situations that impede the Development Team. If the Development Team is experiencing some deficiencies and is unable to do its job well and progress on the developments (technology, tools, or whatever), the Scrum Master role must have the ability and authority to fill the deficiencies immediately.

The Scrum Master does not work to remove obstacles and problems by taking self-directed decisions and actions. The options are always discussed with the team in advance to provide the best solution for them. Whenever possible, the Development Team should solve its problem by itself in the best possible way. The Scrum Master role only supports this activity.

Interpersonal problems and team conflicts

Interpersonal problems and team conflicts are also important occurrences where the Scrum Master role must be involved to solve problems in the most constructive way possible for both the team and the product.

Collaboration with the Product Owner role

The Scrum Master serves as a coach and a supporting role for both the Development Team and the Product Owner role. An important aspect of working with the Product Owner is clarifying User Stories that need details and care for the Product Backlog, which needs to be prioritized and detailed for the next iteration.

Who should be the Scrum Master?

It is of particular importance that the Scrum Master and the Product Owner roles are not taken over by the same person in the Scrum team to avoid conflicts of interest.

If the same Scrum team member is Scrum Master and Product Owner, the Product Owner functions excel and the focus is solely on the product and its fast development. In the end, the Scrum Master role loses some of its importance.

In another unpleasant situation, there may be a Scrum Master that also performs Product Owner functions, which can lead to too much focus on the Scrum team and impair the product’s progress and value.

Both roles require a considerable amount of invested time, and to be performed by one Scrum team member would be difficult. Organizations, teams, products, and business stakeholders may suffer losses.

Working hours of the Scrum Master role

There is much discussion as to whether the Scrum Master role is a full-time position or a part-time role. The official Scrum manuals do not answer these questions either. So we have to think logically again.

For some teams and projects, a part-time Scrum Master role might be enough. In this case, everything has been polished over time, and the problems are resolved and reduced. Everyone in the organization follows the Scrum principles. Business stakeholders look forward to the team completing the planned work at the end of the Sprint. The team is self-organized and focused on its goals.

In another case, if the team is new or Scrum is still an incomprehensible matter to everyone around, the Scrum Master role would be necessary and of particular importance, daily and throughout the working hours.

As the team cultivates respect, work, value, and collaboration, and business stakeholders become accustomed to the ideas of Scrum, the Scrum Master role gradually becomes simply a mentor who is always available and around. The critical need to solve problems and organize events is likely to decrease.

In this way, a Scrum Master can have the capacity, capability, energy, and time to serve multiple teams within the organization at a time.

Scrum Master role as part of Development Team

Another common practice in Scrum teams is to have the Scrum Master take on the role of a technical person who is part of the Development Team. In this case, every time the team needs their Scrum mentor and assistant, the developer takes on the Scrum Master role and ceases to act as a Developer.

Although there are pros to the Scrum Master role being taken over by the Development role, this configuration has its logical drawbacks as well.

In addition to being distracting for a team member to change roles constantly, the Development Role is not likely to fully understand the business needs of the team and the organization. Assistance to the Product Owner role may also be detrimental.

Sprint is a fixed period during which planning, development, daily short meetings and discussions, retrospection (discussion with an analysis of results and processes), and demonstrations of the achieved work are carried out.

Most of the modern products are dynamic, dependent on many factors, and are related to user needs, expectations, emotions, and mood. The development of competition, technology, as well as user habits creates high dynamics in products. Successful teams and companies need to be aware of today’s dynamic business environment.

Scrum and changing product requirements

Scrum offers a solution to the frequent product requirement changes.

The simplest explanation for this solution is that Scrum offers product details that only concern the upcoming Sprint. No matter how big the product is, the Product Owner role should focus on collecting development details that only address the parts of it that will eventually be developed during the upcoming work period.

The Development team, in turn, should also focus primarily on upcoming sprint work. When the Development team has questions and concerns about the User Stories related to the upcoming Sprint, it (the Development team) takes them to the Product Owner role. Sometimes the Development Team may also ask the Scrum Master role, which, however, needs to share the team’s issues with the Product Owner role.

The team is not distracted by ideas that are planned for the future.

Gathering details, describing functionality and product requirements that will not be developed soon will be considered an unnecessary loss as these requirements may change over time based on the feedback provided by product users or stakeholders.

A Sprint is a defined time interval that always has a certain number of days. During this period, the Development team is only working on the planned work for the Sprint.

The Sprint consists of the following events and processes:

• Sprint (Sprint itself, as a complex event)
• Sprint Planning
• Daily Scrums (Daily Team Meetings)
• Sprint Review
• Sprint Retrospective.

Sprints allow the Scrum team to focus on clearly defined and prioritized Product Backlog Items only for a fixed period of time, which is defined and accepted by everyone.

All completed Sprint work is visible to all team members all the time.

The team may try to adapt their efforts during the Sprint.

When a business, the market, and users change and the need to deliver a product is urgent, the visibility of the work helps to adapt and change the direction of development immediately.

Timeframe

Each Scrum event has a specific purpose and a particular time frame (fixed time). The concept of accurate time-keeping allows participants in an event to be clear-headed, more precise, and focused on their goals rather than distracted by unnecessary activities or discussions. It is the Scrum master’s responsibility to ensure that everyone in the Scrum team adheres to the timeframes.

It is up to each Scrum team to decide the length of their Sprint. The duration of the Sprint is consistent, which means that throughout the project (from start to finish), all Sprints must have the same duration.

Equal duration of Sprints has the following positive effects:

The team easily compares the results of the Sprints (work rate, development time forecast).

The team is accustomed to their work capacity and productivity and can make time planning easier.

Work habits and rhythm are built.

How to choose the length of a Sprint?

The Sprint should be long enough to provide enough time and some real results and value to the business and the product at the same time.

Real output and value for business mean that for a Sprint, work (a piece of the project) must be created that is fully completed and can be presented to customers, users, or business stakeholders. Everyone should be able to review and test the finished work and ultimately provide feedback. The result may be approved or may require changes and improvements.

The length of a sprint, according to the official definition in the Scrum Guide, should not exceed one calendar month.

Sprints usually last from one to four weeks.

For guidance, here are some examples that can further help you choose your sprint time.

Choice of short sprints:

You work with technology that quickly and easily produces a real end-result. For example, you use pre-made software, hardware, or electronic components that you only build or assemble and do less finishing activities.

Your product can logically be divided into many small components, modules, parts that you can focus on, and view as standalone elements.

Your client or your directors are impatient and pretty conservative about results. Then it may be politically better to choose shorter periods to satisfy their need for a more frequent review of the outcomes.

Your product and approaches allow you to quickly and easily test your results.

Choosing longer sprints:

The technology used requires more time to achieve a real result. For example, you create complete product technology - software, hardware, or electronic components. You use pure programming languages, you create the elements yourself (through machines, assemblies, etc.).

Testing the result of a sprint (the increment, the finished work) takes a long time and commitment, or depends on external factors.

You have more exhausting processes for delivery, compilation, setup, installation, and other events.

Officially, there are no rules outlined in the Scrum practice regarding the choice of sprint length, and only a brief mention is published about the teams themselves choosing the length of the Sprint. However, BVOP shares the above examples to give you a broader base of ideas.

The whole team must reach a consensus on the length of the Sprint. It is not recommended that anyone makes this decision on behalf of the Scrum team.

Shorter sprints suggest a faster discovery of obstacles for the team. 

Sprint Retrospective

After the work is completed and before you reach the official end of the Sprint, a Sprint Retrospective event is held. The team discusses their work, customer comments, evaluates work, and processes. With shorter sprints, you have more frequent meetings. Problems are defined more often, and solutions are found faster.

Short sprints provide more frequent customer feedback. Thus, the chance of creating unnecessary work or doing something wrong is reduced because the client will identify these irregularities when the increment is demonstrated.

It would make a difference if 1 or 2 weeks were spent on a work that made no sense and served inaccurately, rather than one month, which can result in a very regretful waste of effort and time.

With shorter sprints, the team will likely be able to plan their work more efficiently.

If any project requirement has changed, this change can be identified more quickly and easily.

The most logical time to determine the length of the sprints is at the very beginning of the project when the team is formed and has become familiar with the idea of ​​the project.

Starting a Sprint

Each Sprint starts with a Sprint Planning meeting.

At the beginning of the Sprint, the Development team receives some User Stories (ideas and needs that the customer expects to be made soon), prepared, and prioritized by the Product Owner role.

The development team chooses precisely how many User Stories can be developed through the upcoming Sprint and how exactly the work will be done. Again, no one has to pressure the team to take on more tasks than they can accomplish. The Scrum Master role intervenes in tense situations and recalls that such stress is highly likely to lead to burnout, problems, and defects instead of quality work and a stable product.

Sprint Goal

The Goal of a Sprint is an abstract concept published in the official Scrum Guide, which refers to the idea that the team should set some achievable goals for their work period (Sprint). The goal should explain why the current product increment is being developed and direct the team towards achieving the goal. It is also indicated that the Sprint may be terminated if its purpose becomes obsolete. The goal of the Sprint is defined during the Sprint Planning event by the entire Scrum team.

Popular literature spreads the following purposes of a practical Sprint goal:

• To help prioritize work during sprints.
• It helps to make effective decisions.
• Supports focus during the Sprint Planning meeting.
• Assists teams and collaborations.

Again, these suggestions are quite abstract, like most things in Scrum. The truth is, many teams do not define a Sprint Goal because they do not know what exactly it is for and what to do.

However, let us give you an example to illustrate and discuss how a Sprint Goal can help.

Imagine working on an online platform that allows user registration. You are at the beginning of the project. The Product Owner role has prioritized many User Stories, all associated with user registration related functionality. Let’s set a Sprint goal that will please our customers, users, and all relevant stakeholders of the product.

Sprint Goal:

“Create an opportunity for users to sign up to the platform as quickly, easily, and conveniently as possible without any obstacles or problems.”

This brief plot actually contains a lot of collected information that we need to understand and follow.

We can follow the idea of our Sprint Goal if one of the team members asks the question: “Should I start working on a forgotten password? We have to do it anyway.”

You can quickly answer this question if you remind yourself of the goal of Sprint that the most important thing is the registration form itself, not the side functionality.

Here is another scenario. The marketing department recommends that we add 5 fields in the registration form that users need to fill out.

However, our goal is quick, easy, and convenient registration. We kindly decline and consult the Product Owner role, whether he or she wants to add more fields. If he or she is indifferent, we await feedback from our client. If the client wants more fields, we will eventually add them during the next Sprint. If the client or business stakeholders do not suggest anything like extending the registration form, we have achieved our Sprint goal without distracting ourselves with unnecessary activity. We are reaching our goal.

However, the Sprint Goal may have another valuable application that is not mentioned in the literature.

Imagine your director asking you: “What are you going to do this week?”

Instead of explaining the nature of multiple scheduled tasks, you can simply quote your Sprint Goal.

If you keep defining the Sprint Goal, your CEO or client can just read your definition of the goal if you post it publicly.

When defining your Sprint Goal and writing it down, it should be in the most understandable language for everyone involved in the project.

Sprint Completion

The Sprint must be completed at the end of the last day even if some User Stories are not completed.

Sometimes it happens that some User Stories are not completed.

One idea is to move all incomplete User Stories back to the list of all Product Backlog Items.

The Product Owner role can decide whether to put unfinished User Stories at the top of the Product Backlog. The Items placed above are considered the highest priority. If these User Stories are put back on top, they should be taken on the next Sprint.

However, the Product Owner role may choose to move the unfinished User Stories down the list if he or she believes that for the next Sprint, the team may need to work on something else.

The reason for unfinished work is often that the User Stories are “too big”. This means that there is a lot of work to be done, and the team is unlikely to be able to complete it.

Alternatively, a User Story can be split into many smaller User Stories. The completed parts of it during the Sprint can be composed into one new User Story and all the unfinished parts can become other User Stories, which can be distributed among the next Sprints.

The Scrum Master role, which protects the interests of the team and all good practices for the benefit of productive work, can discuss with the team whether they want to break User Stories into small chunks. After the Development team submits their preferences, the Scrum Master role communicates the decision and choice of the Development team to the Product Owner role.

When the User Stories are split into smaller ones, they are easier to plan and complete.

The problem with breaking down User Stories, however, is that the product increment does not contain everything expected, and this must be discussed with the customer or other business entities.

Scrum has no clear definitions of these issues and cases, so the Scrum Master and Product Owner roles can discuss these topics with stakeholders.

What the entire Scrum team has to be careful about is not allowing many unfinished User Stories. It is often more critical and valuable for both business and product to have a completed User Story than a few somewhat finished tasks.

Ultimately completing User Stories makes it easy to demonstrate a wholesome and fully finished increment. During the inspection (demonstration of progress and the increment), the customer or business stakeholders see developed parts of the product.

Different started and unfinished parts of the product will be of no use to anyone and may only interfere with the accurate assessment of the product increment.

Even if the Sprint is complete and everything is ready, the finished work does not necessarily have to be delivered for demonstration (deployed, installed, implemented). The Product Owner role decides whether the increment (current version) will be presented publicly.

Sprint Review event

The Sprint Review event (meeting) involves the entire Scrum team as well as the roles and representatives of the client or user. During this event, the Scrum team presents the completed work. Scrum has no rules as to who should do this. Usually, the Scrum Master or Product Owner roles present the product increment, but everyone from the Development team is welcome to perform the presentation.

Sprint Retrospective

After the end of the Sprint Review event, the last Sprint meeting known as Sprint Retrospective follows. During this “flashback”, the Scrum Master, the Product Owner, and the Development team come together without the involvement of third parties (any management or customer representatives). The entire Scrum Team (Development Team, Scrum Master, and Product Owner) identifies issues and makes suggestions for improvements for the next Sprint.

After the end of this meeting, the Sprint can officially be considered as finished.

The next Sprint begins on the next business day.

Prematurely stopping a Sprint

A popular term for stopping a sprint prematurely is “Cancelling a Sprint”.

Stopping a sprint means ceasing it and then starting a brand new sprint. Canceling a Sprint should happen in very rare situations and should only be used as a last resort. Various reasons may be the factor for the team to wish to end the Sprint, but the most possible and common cause is a huge and necessary change in product requirements.

The Scrum Master role, as well as the Development team, can offer the Product Owner to terminate the Sprint if they have concerns about the current Sprint and wish to start a new one explicitly.

Only the Product Owner role has the right to terminate the Sprint. The cancellation of a Sprint is a decision of the Product Owner role, which is influenced by the Scrum Master role or the Development team. 

With the cancellation of the Sprint, the entire Scrum team gathers and reviews all the completed and uncompleted work. The Product Owner role can accept the finished work and suggest it is added to the increment, and non-completed User Stories usually go back to Product Backlog.

Each team working on a product or project, regardless of its methodology or operating framework, often estimates the time for task development.

Many teams around the world, especially following traditional Waterfall project management methodologies, use an exactly fixed time to estimate the period required to develop tasks.

Relative estimations in modern product development

Modern product development and project management have, to some extent, found that when tasks are estimated using fixed time, these estimates often turn out to be inaccurate.

Product management has developed more flexible approaches to time estimation. Agile-oriented systems have demonstrated an advantage over fixed-time estimates, in which each task and every effort must have an exact budget and working hours.

Slowly and with difficulty, many businesses around the world suffer inaccuracies and blame their project managers. Project managers on their end criticize the development teams.

This inaccurate approach often leads to stress and failed planning.

Scrum teams are less likely to encounter such problems because they rarely use task scheduling, indicating exact development time, measured in days, hours, or minutes.

30 hours for one task or "L" time for development?

Relatively estimating the time to complete tasks is an approach that can reduce stress and give you a general idea of ​​time, instead of estimating with precision.

Instead of giving an exact amount of time to a single task or User Story, for example “1 day’’, you should use another type of time estimate called T-shirt sizing of tasks. This approach has the same size guide as the one of clothes - S, M, L, XL.

When gathering with your teams and conducting a Sprint Planning meeting to estimate the time needed for your upcoming work, set aside a time that is measurable with relative value for each task.

Some teams prefer T-shirt sizes. Others prefer the so-called "Story Points", which is a time measurement system using numerical values. 

The Story points concept

"Story Points" is derived from the concept of "User Story". We mentioned User Stories many times. In project management, tasks are usually called "tasks". In product management and Scrum practices, however, tasks and User Stories are different things. This is because tasks are based on User Stories.

The entire product that your development team is working on is told in the form of user stories. Instead of describing the scope of the project and writing huge documents of requirements and quality, the Product Owner role simply "tells stories" of all the work that needs to be done. These "stories" are told from the point of view of the product’s users.

Fibonacci numbers are often used as the standard for Story Points, which are used for work sizing:

1, 2, 3, 5, 8, 13, 21

If a project manager listed the task "Creating a Product On/Off Button" and it had an estimated development time of 1 day, the Product Manager or the Product Owner would write a User Story with the content "As a product user, I need to turn on and off the product. " The Product Manager or the Product Owner will then consult with the technical teams, and they together estimate the development time required as Story Points 3.

With these principles of "sizing" work, a User Story that will take very insignificant development time can be written to take "1" work time or "S" work time.

You can define a more significant task as "5" or "L", for example. A huge task may need a "21" or an "XL".

Relative development time comes into conflict with traditional project management practices

Relative development time comes into conflict with traditional project management, because it doesn’t work with precise time and cost estimates, which can be challenging for the senior management.

Agile approaches can be described as a great convenience for the Agile teams, but an inconvenience for the project clients and the senior management.

The Agile product management and project management community can now be said to have "proven" the convenience of Agile approaches to time estimation through relative units.

The lack of precision in the calculations is compensated by the sponsors, investors, and clients. They are increasingly adopting these flexible approaches and embracing the idea that they do not need to know precisely how much their project is going to cost, and they are also starting to think in relative terms. Half a million, one million, two million.

Relativity and product development

Since relativity is the approach of Agile product management disciplines, there is always one fundamental rule and practice in those methods.

Not everything that is planned as tasks is actually developed and implemented in the project. When your product is already "kind of ready" and is usable, stakeholders and sponsors may, at some point, decide to stop developing it.

Discontinuing development, at some point, is a way to compensate for the lack of accuracy in cost estimation. When a product can be considered "relatively ready", it is not necessary for investors or customers to expect all User Stories that are on the Product Backlog list to be completed. If the project is planned for $ 1 million and if the product is just about ready, and the amount spent is about $ 1 million, there is no problem with discontinuing the development. Any improvements and new ideas can always be implemented later.

Recommendation for using relative estimation

When estimating time using relative units, we recommend applying numerical values ​​(1, 2, 3, 5, 8, etc.), especially when planning and estimating development time for more extended periods.

Velocity is a term in Agile product development

Velocity is a term in Agile product development disciplines and is increasingly used today not only by Scrum teams but also by Project Management and Product Management roles.

Velocity is the "speed" at which teams complete planned tasks. It's easy to understand the concept, and at the same time, it's а simple idea.

Velocity needs a fixed period

To be able to measure the "velocity" of a team, some agreed-upon period should be set for active work. This period could be your Sprint.

Calculating Team Velocity

During a Sprint, the entire team completes tasks or User Stories. At the end of the Sprint (a week or two weeks, or any other period), the team completed, for example, 10 User Stories (Product Backlog Items).

Each of these 10 tasks, User Stories or Product Backlog items, had specific Story Points. A Product Backlog item was rated 3 Story Points. Another was rated 8. Some could be 1 or 21.

If we add up the total of these completed 10 items during the Sprint, we get a number. For example, 133.

133 is the Velocity value of the team.

What can we use Velocity for?

Planning Sprint work

After we have calculated the Velocity of the team, it can be easier to predict how many tasks or Product Backlog items can be completed by the Development team in the next period (Sprint).

If 133 was the Team Velocity of the past Sprint, the new planned Product Backlog Items with their Story Points need to have a total sum of about 133.

When that sum reaches a total Story points of about 133, you can count on the fact that those planned Product Backlog Items will be successfully developed by the team during the next Sprint.

Suppose the Development team consists of 5 participants. They all completed 133 points of work.

If you divide 133 work points amongst 5 participants, you will receive 26.6. Let's round this number to 27. So we can roughly say that one member of the Development team completes 27 points in one Sprint.

Business stakeholder and Team Velocity

If a director or business stakeholder asks you to accelerate project work by increasing the size of the team, you may assume the following:

If you add another specialist to the team, the points for the next Sprint, instead of 133, will already be 133 + 27 = 160. Ideally, this means that for one Sprint, the team will complete 160 points of work. Thus, instead of a total of 10 items, these 160 points may include, for example, 15 items. Your business stakeholders will be satisfied with faster development.

If one participant leaves the team, you simply subtract 27 from 133 to get 106. The team can produce such work points during the next period (Sprint) if you are left without one participant.

Once you have the team velocity measured in points, you can theoretically calculate an unlimited number of Product Backlog Items in the future and determine how many Sprints (periods, weeks, months, etc.) will be required to complete all items.

Relativity and Velocity

Some important topics to keep in mind about the Velocity:

The further in time you plan, the more inaccurate your estimates will be.

The longer the team works together, the more work (Story) points they can develop over a period.

If you add a new member to the team, keep in mind that the team needs to unite again before you can predict with greater accuracy the Velocity of your team.

If one participant leaves the team, this does not mean that a certain number of points must be subtracted from the total Velocity. This participant may have worked with different capacities.

Everything is relative.

If you change your technology and tools, Velocity will temporarily decline as teams gain substantial experience with new resources and speed up again.

Various factors in a project or organization can affect Velocity's value.

What is Sprint Planning?

The event that marks the start of each sprint is called Sprint Planning. This is a meeting during which the Development Team and the Product Owner role agree on the type of upcoming work.

Participants in this meeting are the entire Scrum team (Development Team, Scrum Master, and Product Owner role). Stakeholders may be invited to provide additional information, although this is rare, and it is the responsibility of the Product Owner role to provide all available information.

Duration of the Sprint Planning event

For a one-month sprint, the maximum time for the event is 8 hours.

For a two-week sprint, it will be 4 hours, respectively. And so on.

The Scrum Master role ensures that the Scrum team adheres to the meeting time limit, as well as keeping all participants focused and monitoring violations of Scrum principles and rules.

The purpose of the Sprint Planning event

The purpose of the Sprint Planning event is to plan and prepare the work for the upcoming sprint. The planning is done on a group basis, and the whole Scrum Team is involved. This meeting is one of the foundations of the self-organization idea.

The Scrum Master role ensures that everyone is aware of the meeting’s purpose and the benefits of the event.

The Sprint Planning major questions

The Sprint Planning event should answer the following main topics:

What can be delivered at the end of the sprint?

How will the increment work be done?

Resources for productive Sprint Planning

The primary resources needed for this event are the following:

Product Backlog

Latest increment (the latest product version from the last sprint)

Team capacity and velocity

The Product Owner prioritizes items for Sprint Planning

The Product Owner role has previously prioritized Product Backlog Items and may make additional adjustments during the meeting.

Sprint Planning and estimations

The Development team estimates how many Product Backlog Items to choose for the sprint.

Only the Development Team can decide what it can accomplish during a sprint without the other roles putting pressure or influence on it.

After the Development team predicts which Product Backlog Items it can perform during the Sprint, the entire Scrum team together defines a Sprint Goal.

How will the increment work be done?

As there are no formal meetings scheduled in the Scrum Process, at a certain point the Development team discusses how exactly it will develop its tasks. Once the members of the Development Team know what they will be working on, they may need to discuss details, implementation methods, and more. They can approach the Product Owner role and ask questions that will help evaluate the workflow. 

Sprint Backlog

The specific Product Backlog Items that the team has chosen to fulfill in the upcoming Sprint are called the Sprint Backlog.

For example, if the total number of items in the Product Backlog is 200, the teams may include only 10 in their Sprint Backlog.

The Development Team looks at the selected Product Backlog Items for the Sprint together and starts breaking them down into small tasks. The word task here is correct.

A User Story can be broken down into multiple tasks.

For example, if a Use Story describes:

"As a User, I need to create an account."

The team can create many tasks related to this User Story.

One task might be, for example, creating web form fields. Another task might be programming the account creation logic. A third task may be to test the newly created user registration, etc.

The development team can create an unlimited number of tasks that are actually related to a single User Story.

Tasks that are created during planning can also receive a relative estimate of the development time, similar to User Stories. However, many teams, instead of relative values, forecast a specific fixed time for their tasks. User Story tasks may no longer have a relative time, but exact minutes, hours, or days. The development time approach remains the Development Team’s choice.

Freezing the Sprint Backlog at the end of the Sprint Planning event

After arranging the Sprint Backlog list and creating separate tasks for each item, it is strongly recommended that no one else adds or removes Product Backlog Items in that list. Only the Development Team is allowed to manage their Sprint Backlog.

The Product Owner role is not allowed to make any changes or modifications to the Sprint Backlog. If the Product Owner role has a strong need to add or remove an item for some reason, he or she should approach the Scrum Master role and explain its concerns and needs. The Scrum Master role will convey the desire of the Product Owner role to the Development team. If the Development Team agrees, the needs of the Product Owner role can be met. 

Product Owner Role and Sprint Planning Event

Before planning the Sprint, the Product Owner role should have already prioritized the items. The User Stories at the top of the list are the most important.

Another important responsibility of the Product Owner role is to ensure that the items are prepared for the team and suitable for discussion. Everything in the Product Backlog Items should be well described and not have any crucial information missing.

The items should include Definition of Done and possibly Acceptance Criteria. If something remains unclear for the Development Team, the Product Owner role answers their questions.

Development Team and Sprint Planning Meeting

Only the Development Team determines how it works and how much work it can approximately perform during a Sprint.

Even though the Product Owner has prepared the prioritized Product Backlog Items, from which the team forms its Sprint Backlog, the Development Team has the right to decline to work on particular items if they consider them impossible to develop.

The reason for rejecting an item may also be that, for some reason, it is not adequate or working on it will create technical or other problems for the project.

If there are any questionable items on the Product Backlog, it isn’t logical for the development team to select them for their Sprint Backlog. Instead, they can choose from the following items, as it is assumed that the higher an item on the list is, the more significance it has.

The Velocity of the Development teams determines the Sprint Backlog items collection. If in the previous Sprint it was, for example, 130 points, during the Sprint Planning event, the Development Team would select for its Sprint Backlog a total of approximately 130 points.

It is assumed that both inexperienced and experienced teams might make inaccurate estimates at the very beginning of the project or often make mistakes in their analysis and planning. These inaccuracies are natural, and Scrum oriented organizations need to understand this.

As work during the Sprint progresses, it is suggested that the Development Team makes more accurate assessments and has a thorough knowledge of the product, planning, and discussions.

Planning Poker

Evaluating the relative time to complete the Product Backlog Items is also a team effort. It is advisable for a single participant to avoid making an assessment, regardless of his or her role in the team.

Planning Poker is a popular term in the Scrum teams. This is a planning technique through which the Development team puts time estimates to the items planned for an upcoming Sprint by "playing with them like in poker".

Each member of the Development Team holds a deck of cards numbered 1 to 21 or starting at 0 (these numbers represent the Story Points). 

One person on the team presents the User Story aloud and publicly to everyone with all of its details.

Then each participant in this "poker planning game" chooses a card with the number of Story Points, which they think would match the User Story best.

Each Development Team member places their card on the table without showing the card number.

After each team member places their cards on the table, it's time to turn all the cards and see the numbers.

Unless there is a significant difference between each card's Story Points (the participants’ assumptions) for a particular User Story, the average value of all cards is used. The play continues for subsequent Product Backlog Items.

Discussing the estimates

In case the participants' cards show very different values, for example, there is a card with the number 3 and a card with the number 13, the team members who have made these contrasting assumptions start a discussion. The reasons for both assumptions are clearly stated and each party shares its opinion on the estimates.

The discussion seeks to identify the reasons for the contrasting assumptions.

Sometimes the difference may be due to a misunderstanding of a User Story. This misunderstanding may mean that either the Product Owner didn’t explain the User Story well enough or a member of the team didn’t carefully consider the content of the User Story. Another common reason for throwing different cards is the possibility that a member of the Development Team has information that the other participant in the game (the one with the contrasting card) does not know.

Let's give an example.

On one hand, a “low card” participant may know a very easy method to implement a functionality or embed a component, and the other members may not be aware of that easy method. This is the reason why the participant chose a small number card.

On the other hand, we may have the following case. The player (participant) with the highest card, who should typically open a discussion with the participant with the smallest card, may already have tried this "easy and fast" way of getting the job done. It has been found that the easy way may only create additional problems. The opponent with the weak card is not yet aware of this fact.

The discussion serves to identify problems, opportunities, and solutions. The debate is done while the rest of the team is present. Anyone can take part in the topic if there is something to add and to help find the right solution. Otherwise, the discussion may go beyond a reasonable time frame.

After the discussion, a re-play is performed, and each participant of the Development Team throws a card again. Other participants' opinions may already have been influenced.

Card throwing and discussions are made until consensus is reached.

Independence among members of the Scrum Development Team

The Planning Poker meeting aims to achieve independence among members of the Development Team and provokes the idea that anyone can throw their card without worrying about the rest. No one should throw their card after the Development team has already revealed the card numbers.

Often, new members of the Development Team are very distracted by this "game" and are afraid to throw their cards until they somehow understand what cards were thrown by senior team members.

This practice also aims at transparency, individualism, and openness. The aim is also to develop time-assessment skills among newcomers.

Keep in mind that this approach is just a popular technique for estimating development time. Each team can choose its own transparent and effective ways.

Scrum Master and Product Owner may not participate

Scrum Master and Product Owner roles do not have regulated official participation in this technique. The Scrum Master role participates in its discretion without interfering with the team and can monitor transparency, respect for team members, and honesty.

The Scrum Master role encourages involvement and teamwork and condemns behavior that would violate fair play principles. He or she makes sure that the duration of the Planning Poker is reasonable, as it is only part of the entire Sprint Planning event. Some teams distinguish between the different planning meetings. They separate them from their official Sprint Planning, during which they have discussions, select specific work for the Sprint Backlog, split their tasks, and create a Sprint Goal (if they need one).

How many Product Backlog Items should be estimated?

There are no official rules for how many Product Backlog Items should be estimated during this "game".

If the team is in their first project Sprint, it is advisable to “play” as many items as possible in a reasonable amount of time.

If the team is in another Sprint, they can “play” an approximate number of User Stories, which can be completed by the Development Team during the Sprint.

We recommend that you estimate a few more additional items because if the Development team finishes their work earlier, they can "insert" a few additional Product Backlog items into their Sprint Backlog that have already been evaluated. It will be very easy to determine exactly how many items to add in the remaining days of the sprint.

Planning Poker is not practiced by all Scrum teams, as this "game" can take a long time, and the team may experience inconvenience and distress over time. Time estimation can also be accomplished through faster group discussions by the Development team.

When there are ambiguities or missing information on some items, and it is not possible to retrieve additional information, the Development team, in theory, should still be able to evaluate them by assuming the most accurate estimate possible.

After the evaluation “game”, the selection of work for the current Sprint, and all discussions end, there comes another interesting practice, which can be initiated by the Scrum Master role.

The Sprint Success prognosis 

Each member of the Scrum team indicates a number from 0 to 3, thus personally and individually proposing their success to the Sprint. 0 means failure (Unfulfilled sprint goal, work in progress, or problems). 3 means success and achievement of all initiatives. Collect the sum of points. Considering the total number of participants and the total points for the success of a Sprint, a high or low overall value is predicted.

If the result of the averaged points is not satisfying, have a discussion, and indicate possible problems.

If the scores for success are high, the Scrum Master role thanks everyone for the active participation and closes the Sprint Planning meeting.

Sprint Planning and Time Consumption

If your Sprint is 1 month, your Sprint Planning will be one full working day. You will have to keep in mind the colleagues are sometimes late, there are lunch breaks, coffee breaks. Observe reasonable limits for such events and seek optimized discussions, processes, and results.

The Scrum Master role interrupts all Scrum events, ceremonies, and meetings on time so that valuable time is not wasted.

Variations of the Sprint Planning details

The different teams have many variations of estimating the time it takes to develop the Product Backlog Items. The Story Points estimates that the teams make, however, are not always carried out during the Sprint Planning event.

Sometimes you may conduct additional informal meetings and events such as Product Backlog Items Grooming Meeting and various others. These are special meetings that bring the whole team together again to evaluate time and hold discussions about Product Backlog items. Some teams also have separate time assessment meetings and separate Product Backlog Items discussion meetings.

The explanation

At the end of the Sprint Planning event, the Development Team must be able to present to the Product Owner and Scrum Master the way it intends to work as a self-organizing entity to achieve the purpose of the Sprint and to develop the expected work.

The original text in the Scrum Guide:

"By the end of Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment."

We prefer not to interpret this abstract paragraph from the official Scrum Guide and leave the interpretation to you.

BVOP suggests the Scrum Master or Product Owner do not “cross-question” or conduct "behavioral interview" dialogues and do not provoke unnecessary problems. Scrum Master and Product Owner roles should be reasonable and expect the same from the Development Team.

Let the whole Scrum team know precisely what it will work on and for how long. Keep the technical approaches clear. Other topics stemming from the original Scrum statement can be cited as familiarizing the entire Scrum team with the theory of self-organization.

The Daily Scrum is a limited-time event during which each member of the Development Team presents to the others very briefly what they did the previous day, what they will do today, and what problems and obstacles they have encountered or anticipated.

This event is typical of the Scrum framework and is mainly used by Scrum teams.

During the event, the members of the Development Team answer the following sample questions:

• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediments that prevent the Development Team or me from meeting the Sprint Goal?

Team members can ask their own questions. They invent and configure the questions themselves. To achieve a daily team balance, a different team member can be in charge of asking the questions. It is common practice for the questions to be asked by the Scrum Master role, but it is not necessary.

Participants tell short stories. Discussion may also take place. All details, however, which require more information and time are held after the meeting.

The purpose of the Daily Scrum

The purpose of this event, in theory, is to increase transparency, efficiency, better work inspection and allow solutions to potential problems.

Participants share with others what they are working on, making their work transparent to others. Transparency makes it easy to inspect the work, identify any problems, and find appropriate solutions with the help of other members of the Development Team.

After discussing all development issues and obstacles, the team reviews their Sprint progress to see how it’s doing. Burndown Chart is a traditional chart that shows work progress by visualizing the work done and the work remaining.

According to the data in the chart, plans can be modified if necessary to meet the Sprint Goal.

The team is entirely self-organized. No one outside the Development Team interferes with the inspection and adaptation processes of the team.

Features of the Daily Scrum event

All members of the Development Team are present.

The meeting is held daily at the same time and place.

The meeting has a maximum time of 15 minutes.

The time limit is intended to promote efficiency and prevent loss of focus.

The Scrum Master role makes sure that everyone is focused during the meeting, shares their answers to all three questions, and at the same time, takes care of the brevity.

It is a common practice among the Scrum teams to keep the team members standing up (stand-up meeting) during the meeting. Because of this, sometimes the unofficial event name is the Daily Standup Meeting.

The idea of a stand-up meeting is to make it a bit less comfortable, which will result in less time extensions.

The Daily Scrum event is not a report

Many teams have the daily scrum event as a simple overview of their daily tasks, which at the end looks like a common report, rather than an active collaboration.

The Scrum Master role must support the idea of ​​self-organization and the achievement of the Sprint goal. If the team is not very proactive, the Scrum Master role should provoke them to look carefully at the situation and to understand what others are sharing. The Sprint Goal must be achieved. If this means a work review or an immediate change in tasks, the team should do it.

The business value and the work of the team

Scrum mentions the topic of business value though no specifics are given. However, all Scrum participants must strive to deliver business value as it is the most important thing that the entire Scrum team provides for the product.

During the development process, the Development Team not only has to strive to complete Product Backlog Items but also strive to deliver business value for the product. As Scrum encourages the team to choose their own way of working and the exact way they will do their job, there remains the risk of insufficient value for the completed tasks.

The development team must be provoked to do the best job it can. Business value can be found in any initiative.

Tidier code can provide easier maintenance in the future and save time. Being diligent in one web-based user registration form can provide more customers and fewer disappointed users. Business value can also be delivered through communication, where the team asks important questions about the essence of the product idea.

Who are the participants in the Daily Scrum event

Participants in the Daily Scrum event are the Development Team and the Scrum Master role.

The presence of the Product Owner role is not required, but this role may be present if the team wishes and needs his / her knowledge and advice.

Any detailed discussion of a task should take place after the meeting. The Product Owner role should in no way attempt to influence the Development Team through its presence or to make its presence mandatory.

The Development Team conducts its meeting, inspects its work and progress. No one questions the Development Team about the tasks completed and the tasks remaining. The Burndown Chart is not a reporting tool to the Scrum Master, Product Owner, or outsiders.

The Scrum Master role does not put any pressure on the Development Team related to work progress, nor does the Product Owner role when attending (Daily Scrum) meetings.

Outside parties and business stakeholders are not allowed in the Daily Scrum event.

The Scrum Master role ensures that the Development Team executes the event, that the 15-minute limit of the event is respected, and that no external pressure is exerted on the Development team. These are the only formal responsibilities of the Scrum Master role related to the Daily Scrum event.

Informal responsibilities of the Scrum Master role related to the Daily Scrum event

A team meeting can have many obvious or hidden issues. These problems are sometimes left unresolved and continue to exist.

If during a Daily Scrum event, Development Team members look directly in the eyes of the Scrum Master, Product Owner role, or some designated senior member as they speak, this may be an indicator of anxiety or expectations to be led by others. These factors are signs of impaired self-organization, cohesion, and proactivity.

As many teams and organizations exist, so many possible problems exist in the day-to-day work of teams. A business person, or even a customer, may require a member of the Development Team to report in writing or receive orders without anyone else in the team knowing.

Whatever problems are noticed inside the team or throughout its meetings concerning all Scrum principles, it is the informal duty of the Scrum Master role to resolve them in some way. Sometimes these problems may not be solved due to more advanced factors, which can’t be influenced by the Scrum Master role.

BVOP recommends that in any Agile-oriented organization, there is an Agile Director position. Its purpose is to address the Agile teams’ problems that the Scrum Master role lacks the authority and power to solve.

The Agile Director should be seen as part of the senior management, not as part of the Scrum team.

Potential sensitive situations related to the Daily Scrum event

Situation

You receive an email from the marketing department. Since they do not know where the Daily Scrum is located, they ask you to indicate the place in advance so that they are not late for the meeting.

Reaction

Members of other teams or departments should not attend the Daily Scrum event. It is up to the Scrum Master to explain these details to outsiders and to deny access to the event.

Situation

Your client's representative is coming to your office during a short business trip. He is leaving early in the morning the next day. Fifteen minutes before your meeting, a member of the Development Team asks the Scrum Master to invite him to provide as much relevant information as possible while he is here.

Reaction

In theory, the event should not be attended by external participants. However, since a member of the Development Team is expressing interest, it is unlikely that this will be a problem, and the Scrum Master role can assist and ensure the involvement of the client representative.

However, since only one team member presents this interest, it is appropriate that the other members of the Development Team are informed of this request and also agree with it. The Scrum Master role must understand the views of all team members before inviting the representative.

Situation

A member of the Development Team was late for the Daily Scrum meeting, therefore, sending the following email with answers to common questions typical of the event:

"Yesterday, I worked on password recovery. The functionality is not yet finished. Today I will continue working on it. I think by the end of the day, I will succeed. I encountered a few problems, but I got around them.

Reaction

At first glance, such information seems commonplace, as it indicates what your colleague worked on and what he will do today. It is also explained that problems have occurred. However, the information cannot be considered as exhaustive and satisfactory for other participants in the Development Team, who may need to understand the specific problems their colleague has experienced.

It is up to the Scrum Master role to request additional information as soon as possible after the Daily Scrum event. The Scrum Master role then shares the information with the entire team.

Situation

The Product Owner role comes to the Daily Scrum meeting just before the end of the event. They ask everyone to kindly repeat the shared information because in a short while they (the Product Owner role) will meet with a customer representative. The client has requested up-to-date development status, and the Product Owner role wants to satisfy the client's needs.

Reaction

There are many possible reactions to this situation, but the most important result is keeping the Development team calm. The Product Owner role, in theory, should not be present at this meeting, nor should it require such information.

However, such a situation is delicate and, in some way, needs to be addressed to satisfy all parties. An easy way out is to provide the necessary information to the Product Owner role. The Development team shares specific information with the Scrum Master role. The Scrum Master then passes the information to the Product Owner.

It is strongly recommended that the Scrum master is up to date with the daily progress of the Development team so that it can react with ease in such situations and not disturb the workflow. 

Scrum Master and Product Owner roles can play a part in customer satisfaction while the Development team continues to work peacefully to meet the Sprint Goal.

Situation

Just before the Daily Scrum meeting, your Director sent the following email to the Scrum Master role:

"Can colleagues from another department come to your daily team meeting to monitor your Scrum events and gain valuable experience. I guarantee that they will not interfere in any way."

Reaction

Again an interesting and likely to occur situation. Outsiders should not attend the Daily Scrum event. However, to deliver business value to the entire organization, the Scrum Master role may consider facilitating the training of other teams as they attend real Scrum events.

Discussion between the Scrum Master role and the Development team can take place. If the Development Team doesn't mind, then the Scrum Master role may invite an external new team to watch from the side. 

Situation

A member of the Development team wants to invite the Product Owner to the Daily Scrum event in order to share information. All of the other members are against that as they don’t want the Product Owner to find out essential increment implementation details.

Reaction

Since the team can not come to a unanimous decision, the request to invite the Product Owner should get rejected. However, another issue occurs in this situation. If the team doesn’t want the details of the increment’s work disclosed, this means that there might be something wrong. Complete transparency is lost and technical questions are kept in secret. A good practice would be for the Scrum Master to evaluate the situation and find the real reason for the disagreement.

Sprint Review is a Scrum event that takes place at the end of a Sprint. The Scrum Master role supports this event, ensures that the meeting takes place at the right time and that all participants understand its purpose.

The purpose of the Sprint Review event

Sprint Review is conducted to demonstrate what was completed during the Sprint, to seek and receive feedback, and to encourage cooperation between all parties in the project.

Event attendees inspect the increment and, if necessary, adapt the Product Backlog.

The goals of the Sprint Review event are:

• A review of what exactly was achieved during the Sprint.
• Product increment inspection.
• Adaptation of the Product Backlog.
• Obtaining helpful feedback for the next Sprint.

Duration of the Sprint Review event (meeting)

For a one-month Sprint, the total time for this event is 4 hours. For two weeks - respectively, the event is 2 hours maximum. For a one-week Sprint, time is limited to 1 hour.

The Scrum Master role keeps track of time and focuses on essential (for the meeting) topics.

Participants in the Sprint Review event (meeting)

The whole Scrum team and various stakeholders.

A Product Owner role that invites key figures to the meeting at its discretion.

End-users may also participate in the event.

Done work

Remember Definitions of Done. Each item in the Sprint Backlog has a clear definition for completion. Officially the Product Owner role during this event accepts or rejects the work done, citing the Definitions of Done.

If work is well created, but a small part of Definitions of Done is not fulfilled, the Product Owner role may declare the item unfinished. It is good practice not to accept such uncompleted items, as a small detail or unexecuted procedure can create a problem. However, the Product Owner role may accept items that do not cover all Definitions of Done completely. In theory, the Product Owner role should not do this.

The Product Owner role returns unfinished items back to the Product Backlog at its discretion. It is the most common and logical practice for those items to be planned for the next Sprint.

The demonstration

A demo is a fairly common name for this event. However, keep in mind that product demonstration is only one part of the entire Sprint Review event. The term demo often gives the wrong idea about a Sprint Review event.

Some teams do not make a demonstration at all and transfer this part of the event to the Product Owner role. They can also directly notify the customer and stakeholders when there is a ready-to-view part of the product.

The typical review has its benefits for the Scrum principles of transparency, inspection, and adaptation. During the review’s comments from customers or customer representatives, there is an opportunity to observe the spontaneous reactions and impressions of attendees.

The comments and feedback are direct, instant, and first-hand. This information may be more valuable than presenting analytically ordered data after the review, as the Development Team can capture the nuances.

Sometimes the client may not express his or her opinion clearly or precisely what he or she thinks about a particular issue. Still, the reactions, body language, exclamations, and comments reveal valuable information.

However, participants who monitor and inspect the increment must provide some formal and understandable feedback to the Scrum team. This often happens during a Sprint Review event, but the Product Owner role can receive a lot of additional information, comments, notes, or questions after the event is finished.

The next step is the discussion of top priority Product Backlog items. Stakeholders can come up with ideas for necessary refinements that need to happen right after the demonstration (during the next Sprint).

Some Product Backlog items may be referred to as lower priority or may be dropped altogether.

Not only business-oriented people or customer representatives participate in the discussions. The Development Team observes, listens carefully, and can also offer their opinion.

Businesses or clients can ask the Development team questions about the increment. The Development Team strives to respond according to the situation’s needs.

The result of the Sprint Review event

The result of a Sprint Review event should be:

• Presented increment
• Received feedback
• Constructive discussion
• Prioritized Product Backlog
• Release Plan (When exactly or how exactly the increment will see the light of day in front of other business representatives or directly to end-users).

The Sprint Review event may also include additional topics. Those may be indicative estimates of time, budget and cost, market dynamics, consumers, potential new opportunities, and the business value of the product.

Although these are important and interesting business topics, these parameters should be more closely related to nearby upcoming Sprints (at best the next Sprint). It is advisable to avoid plans and projections for the distant future.

The demonstration, feedback, discussions, item rearrangement can be defined as "sub-events" in the whole regulated Sprint Review event.

Starting and ending a Sprint Review event may not always be the same. The Product Owner role invites business stakeholders and various representatives or users. There may be many participants and factors involved. Sometimes the client does not come to the meeting or sends different people each time.

The sequence, format, specific details of the event will depend on the client (or their representatives) or business stakeholders of your organization.

The Sprint Review event, with a one-week Sprint, has a limit of 1 hour. For all discussions, inspections, reviews, item arrangements, comments from various business people, the time allocated for the event may not be sufficient. Respecting the time limit is a real and serious challenge.

In the real world, Scrum rules are often broken. Businesses may not know them or may not be interested in the Scrum recommendations.

The Scrum Master role should interfere with such situations and explain that interrupting the process hinders work and complicates planning.

Sensitive situations and reactions related to the Sprint Review event

Situation

Everyone starts gathering for the Sprint Review event at the usual place. It turns out that the attendees are the Scrum Master role, the Development team without the beginner participant, the Client-side Project Manager, the Client-side Product Manager, Business Analyst, and an external Usability consultant.

Reaction

The Product Owner of your Scrum team needs to be called, as it is a key and important role that should be present. The new member of the Development Team is also advised to be present to familiarize themselves with the atmosphere and processes of the team and organization.

Situation

A project manager from your organization attends the Sprint Review event. He listens and observes everything that happens carefully. He is pleased that the work is going well. Finally, he turns to the Scrum Master role and asks when the product increment is expected to be released in a live environment.

Reaction

Project management topics related to defining milestones are not the theme of this event. It is recommended that the Product Owner role discusses these issues with the project manager after the event is over.

Situation

An outside business person asks the team’s Scrum Master if the product increment can be presented to real users this week.

Reaction

Let's first recall what a product increment is.

During the Iteration (Sprint; the period during which the Development Team works), the Development Team works collaboratively to create a Potentially Shippable Product Increment.

The "Potentially Shippable Product Increment" is a working version of the product in development that can be made available to end-users. These "product increments" must be fully completed for the duration of the Sprint. There should be no hidden work that still needs to be done.

The inspection is carried out on the increment, and any adjustments made aim to create a better and more valuable product.

The Potentially Shippable Product Increment is the version of the product that is inspected and reviewed during the Demo but is often not the real product. It's just "potentially ready".

Without experience in product development, testing, and release processes, one might be left with the impression that the increment is a real product. It is a common practice to work on a test version that is accessible only to teams, customers, or business entities, and not to the outside world.

At some point, the increment is delivered in a real environment. The Product Owner role is responsible for the release.

When the Scrum team works for a client, they usually ask them first about releasing the product in a real public environment.

When a product is developed for a particular organization, its Product Owner role may have the power to make the release decisions on their own.

The Scrum Master role should not be relevant to both the increment and the released product.

To summarize, the Scrum Master role should not be relevant to this question and should not offer answers but instead transfers this topic to the Product Owner role.

The Product Owner role must have the competencies and skills to provide adequate answers and to participate in discussions related to the future planning, budgets, and direction of the product as a whole.

All of these discussions should take place after the end of the Sprint Review event.

Situation

Shortly after the beginning of the Sprint Review event, the client's product manager brings up the topic about the project’s budget. The product manager is not sure if the resources of his organization will be sufficient to continue working on the product for another six months. He also asks the Product Owner for comment and advice on the Roadmap of the product.

Reaction

This particular topic should not be brought up during the Sprint Review event, as it is not the aim of the meeting. The Scrum team, and especially the Development team, would engage in conversations that are not within their competence and importance.

Such a dialogue would only distract the participants. However, this is an important topic, and the Product Owner role should be involved and ask the client's representative to remain patient and wait til the end of the event.

The Product Owner role can engage in such discussions with the client’s representative if they have the competence to do so. The BVOP recommends all Product Owner roles to be proficient in topics such as budget and future development of the product, as well as participate actively in Roadmap planning.

Situation

The client's product manager does not approve Definitions of Done for one of your User Story and refuses to accept the finished development. Everyone turns to the Scrum Master and Product Owner roles of the Scrum team waiting for a response.

Reaction

The initial spontaneous reaction of most Product Owner or Scrum Master roles would be to satisfy the claims of the business representative who has remarks about various artifacts.

When the product manager is allowed access to the Scrum team’s work materials, another inadvisable situation occurs.

BVOP recommends sharing the Scrum team’s materials with outsiders only if they are competent enough, as this may significantly improve the transparency and collaboration process. Otherwise, delays and waste may result.

It is up to the Scrum team to decide whether they prefer outsiders to have access to their resources. The reason for such shared access would probably be a desire for collaboration and teamwork.

If a productive and collaborative atmosphere is established between the organizations then the described case can be considered valuable and important.

When there is a mutual synergy between the teams of both organizations or there are regulated official rules for material inspection by the other side, the Product Owner role should pay attention to the comments made.

Definitions of Done can be adapted and modified as needed.

Situation

Just before the end of the Sprint Review event, a team member says out loud that a User Story covers all Definitions of Done. However, the finished work is not visually the same as the sketches in the specific Product Backlog.

Reaction

The materials provided in the Product Backlog Items serve as a reference and guidance for the Development Team. Often, there is nothing wrong if the real result doesn’t match with a sketch. The Development Team decides for themselves how to get the job done and what the product increment can provide at the end of the Sprint.

If all the terms in Definitions of Done are covered, and all tests have been passed successfully, then these positive results show excellent work. If stakeholders also have no claims about the product increment, this is the final indicator of successful work.

The appropriate reaction for this situation would be for all Scrum team members to discuss their way of working and processes.

When the Sprint Review ends, the last Scrum event called Sprint Retrospective follows.

This is when a lot of things can be balanced.

• Was The Development Team Successful?
• Was the entire Scrum team successful?
• What was done well and what wasn’t?
• Why did positive and negative events occur?
• What could change?

Sprint Retrospective is a Scrum event that happens at the end of each Sprint and before another one begins.

The event should help the Scrum team improve their practices, identify problems more efficiently, and deal with them more adequately.

Each Scrum team, whether beginner or advanced, must perform Sprint Retrospective. This event is a significant part of the Scrum framework. A Sprint Retrospective is a meeting at which the team discusses the recently completed Sprint and makes an action plan for the upcoming one.

The Scrum Master role is a leading figure during this event. It motivates the entire Scrum team and teaches everyone the benefits of the event. It makes sure that everyone is engaged and participates and again, aims for transparency and initiative. If the entire Scrum team has to learn particular lessons, this event is the perfect time for them to be presented and taught.

The Sprint Retrospective Event aims to inspect and adapt just like most Scrum ideas. This time, inspection and adaptation are not about the product, but the team, the attitude, and productivity.

The Sprint Retrospective Event (meeting) questions

The Sprint Retrospective Event addresses the following fundamental questions:

• What went well during the Sprint?
• What went wrong during the Sprint?
• What can be done differently and better in the next Sprint?

The Scrum Team needs to be able to evaluate everything in its Sprint very thoroughly. If a process has been an obstacle, the team may decide to suspend it. If any change is considered necessary, it should be carefully analyzed, planned, and set in motion.

By conducting regular retrospectives after the end of each Sprint, it is assumed that the Scrum team will become better, the processes more useful and flexible, and the obstacles less.

Obstacles

Continuous improvement includes removal of obstacles as well as constructively discussing the situation at the end of the Sprint. The Scrum team can identify obstacles and focus on their subsequent elimination and identify valuable remedial measures.

An obstacle can be called anything that slows the team down or prevents the team from providing business value. It is the responsibility of the Scrum Master to identify, track, and remove obstacles, or to assist the team in removing the obstacles themselves.

The Daily Scrum event (meeting) is the perfect time to share problems. If they are recorded in advance, all documented issues can be discussed in detail later, which would make it easier for the Scrum Master to work on them.

The faster the teams discuss the occurring problems, the easier it is to sort them out.

It is important to find the source of the problem instead of just discussing the obvious issues. The improvement methods depend on the severity and the cause of the problem.

Who helps solve problems of all kinds?

The Scrum team should try to fix their problems on their own. The team must be mature, responsible, self-initiated, and self-organizing. The development team is self-driven. Scrum Master and Product Owner roles also do their best to solve problems. However, if the Scrum team fails to cope with a problem, it must seek help and assistance beyond its configuration.

Scrum looks like a closed loop, a cycle, and a process, but it should not be considered that way. Assistance can come from both the client and the organization you work for.

In addition to looking for recording, and eliminating problems and obstacles, the Scrum Master role is also responsible for encouraging others to do the same. The Scrum team does not have to wait for the Scrum Master role to resolve all issues.

It’s a good practice for the team to keep a list of their problems, just like the product has one for all the work that needs to be done.

Prioritize the issues by importance, power of influence, frequency of manifestation, or other defined parameters. Statuses can be assigned to any problem. Some problems might be under consideration, some pending, and others might be resolved. You can also assign yourself "responsible" for any challenge. Each team member should be willing to help themselves instead of waiting for the Scrum Master role to appoint a responder.

An indicative time can also be set to solve each problem. You can also create a "vote" for each problem if this will help with prioritization. Each participant can state their vote on an issue. To make the process more flexible, one can use a technique in which each participant has the right to rate the problem from 0 to 3.

Who are the participants in the Sprint Retrospective event?

The entire Development Team and Scrum Master role are required to participate.

The Product Owner role is optional. If the team needs their Product Owner, this role can be invited to discuss product issues. Although Scrum rules do not require the participation of the Product Owner, his/her attendance is recommended. Surely there will always be something to discuss concerning the Product Backlog, the product itself, business needs, issues, the direction of actions.

The presence of the entire Scrum team also affects the union and relationships between all participants.

Negative presence of the Product Owner role during the Sprint Retrospective event

The very presence of a Product Owner role can be a hindrance and a problem for the Development Team and make some (or all) of the members uncomfortable.

The Scrum Master role should deal with this obstacle for the team by politely explaining this problem to the Product Owner role.

For the future, this issue should be discussed with the Product Owner role and resolved.

Negative presence of the Scrum Master role during the Sprint Retrospective event

The most unpleasant situation will be if the Scrum Master makes the Development team feel uncomfortable, which makes him or her an obstacle.

As this is a problem that can’t simply be removed, the Scrum Master should self-monitor, self-inspect, and seek regular feedback from all members of the Development Team. They should work on their personality, mood, behavior, and professionalism when such a need for improvement is identified.

Sprint Retrospective event and business stakeholders

Business stakeholders rarely attend the Sprint Retrospective event. In theory, their presence, according to Scrum principles, is not allowed.

However, a possible reason for business stakeholders to participate in the Sprint Retrospective event may be, for example, the strengthening of the relationship between the Scrum team and the organization (or client). All parties can get acquainted with the problems of others and understand the specific details.

Occasionally, inviting stakeholders can be practiced if the entire Scrum team believes that this approach would be useful.

Sprint Retrospective event and Scrum Master role

To summarize, the Scrum Master role has the following objectives related to the Sprint Retrospective event:

• Takes care of the productive, open, honest, and appropriate environment and atmosphere of the event.
• Provokes the most basic questions like "What did we do well?", "What didn't we do well?" and "What can we improve for the next Sprint?" and seek their answers.
• Records all opinions and comments.
• Recalls information and comments from a previous Sprint to be considered and eventually discussed.
• Encourages the equal participation and activity of all present.
• Keeps records of problems.
• Provokes participants to solve problems.
• Manages archives from previous meetings.
• Indicates important points from the past if there is a need for new discussion and if the problems are still unresolved.
• Focuses participants' attention to the goals of the event and aims for effectiveness.
• Keeps track of the meeting’s time limit.
• Provokes new thinking and ideas as he/she tries to develop the team in the direction of solving its problems.
• Directs attention to the most productive ideas and goals of the team.

The notes on what is done well, what is not done well, and what needs to be improved can be stored in a tabular form as follows:

What have we done well?	What have we not done well?	What can we improve?

 

Retrospection discusses what happened during the Sprint. Everything negative and positive is indicated and described. The idea of ​​how improvements can be implemented is also described.

Problems and obstacles can vary and are recorded not only during the Sprint Retrospective event. The Scrum Master role can keep an archive based on the topics discussed during the Daily Scrum event.

Duration of the Sprint Retrospective Event

For a one month sprint, the maximum event time is 3 hours.

For a two-week sprint, the event is an hour and a half, respectively.

What is the Burndown chart used for?

The purpose of this graph is to show the progress of the Development Team during the Scrum Sprint.

How to create a Burndown chart?

Most modern Scrum management software tools have built-in Burndown chart generation functionality. Each time the Development Team completes the task, your Burndown chart will update itself. We recommend that you carefully study the settings of your software’s tools and the way they work.

You and the chart

The most important thing to know is that the Burndown chart is not as scary as it may seem. Another essential thing to remember is that you should view the Burndown chart daily. Traditionally, this is done during the Daily Scrum meeting.

Here's an example of how a Burndown chart might look like.

Explanation of the elements of the Burndown chart graph.

The left axis is vertical and shows the total amount of work planned for the Sprint. If all items in the Sprint Backlog have a total of 600 Story Points, the left vertical axis will show 600 (top left). Another line descends down and to the right, ending at the end of the horizontal axis (bottom right).

The horizontal axis shows the time of your Sprint. The rightmost part is assumed to be the last day of your Sprint.

The leftmost part of the horizontal axis is accordingly the first day of your Sprint.

Note the gray line on the example above, which starts at the top of the left vertical axis, and ends at the right-most part of the horizontal axis. This is a starting line that does not change and is a benchmark for your Sprint.

The red line shows the real movement of the Development Team and its progress. Every day your real (red) line of work moves from top to bottom and from left to right. The goal is to reach the gray orientation line at the end of the Sprint.

Analysis

When your real red line is moving above the guidance line, it means that sprint work is behind schedule. If the real (red) work line is below the ideal gray line, logically, your Development team is advancing faster than planned.

Let's analyze the chart above

You may notice that during the first two days of the Sprint, the Development Team completed their work slower than expected. On the third day, however, the team was able to catch up with the delay, and the real red line even went under the ideal gray line.

By day 6, the team is moving faster than expected. The red line is still below the gray line. After the 7th day, the work is slowed down again. A period of 3 days is observed during which the red line does not drop down and moves horizontally. Horizontal movement means that there is no real progress on the tasks. Then we notice that the red line is starting to move very slowly downwards.

Any sharp vertical drop of the line means that one task or User Story is complete. You can see about 25 line movements, which means that there are approximately 25 tasks. Each time a team member completes a task, and the task is marked as Done, Ready, Finished, or another similar status that your software automatically monitors, the line moves down.

However, you also notice strange slight upward movements that immediately revert downwards. Such changes can mean different things, but most of all, the team has added new small tasks to their Sprint Backlog list, modified task execution time, or swapped tasks.

The other thing that strikes the sample chart above is that the team is unlikely to be able to complete the planned Sprint job. It is noticed that the end of the red line is not quite close to the end of the ideal gray line. Still, half a day remains until the end of the Sprint. If the team completes all the planned work, the red line will have a sharp drop down and reach the ideal gray line (the end of the Sprint). The red line will touch the gray line.

The Burndown chart may, in some cases, not reflect the real situation. If the Development team forgets to mark their work as completed, the software will not update the schedule. It will appear that the planned Sprint work is far behind schedule. If your software tool requires manual graphics updating, you should do so to have a visibly up-to-date status on team progress.

The Development Team and the Burndown chart

The Development Team freely observes and discusses the Burndown chart. If the team notices that Sprint progress is too fast, it may pay attention to the quality of work or consider whether all Definitions of Done and Acceptance Criteria are met.

In the event of work delays, it will probably be necessary to take measures. However, they should not impair the quality and all defined criteria of work.

Scrum Master role and the Burndown chart

The Scrum Master role has no regulated rules related to the Burndown chart. BVOP, however, recommends that the Scrum Master role assists in supporting the Burndown Chart and shows each Scrum member the benefits of the chart’s application. The Scrum Master role should assist during slow and fast-moving Sprint periods.

Product Owner role and Burndown chart

The Product Owner role has no real practical involvement in the Burndown chart but can still benefit from it. Monitoring progress can be important to their work and responsibilities.

If the work progresses too fast and all User Stories are expected to be completed before the end of Sprint, the Product Owner role can quickly notice this in the graph and prepare User Stories that can be further implemented in the Sprint Backlog.