Product Backlog nurturing – table of contents:

1. Introduction
2. Purpose of Product Backlog nurturing
3. Errors in Product Backlog maintenance
4. Backlog maintenance vs. metrics used in Scrum
5. Summary

Introduction

Product Backlog is one of Scrum’s Artifacts. It contains a prioritized list of work needed to create a Product. In other words, it is a list of User Stories necessary to achieve the Product Goal. You can find a detailed description of what User Stories are in this article. And here are the details on the characteristics and how to maintain the Product Backlog.

Product Backlog nurturing also goes by the following names:

• Backlog Prioritization,
• Backlog Refinement,
• Backlog Scaling.

Purpose of Product Backlog nurturing

The Product Owner manages the Product Backlog. The key skills include prioritizing tasks as their due date approaches. This is because the goal of Product Backlog nurturing is to make sure that the Product functionalities come with the highest business value, i.e. those most essential from the Customer’s point of view, are at the top of the to-do list. And their description is clear and detailed so that their implementation can start right in the next Sprint.

The Product Backlog can get updated daily if needed. The Product Owner can add new User Stories to the Product Backlog after talking to Stakeholders and the Development Team, or by drawing conclusions and reformulating User Stories already written in the Product Backlog.

Mandatory updating of the Backlog is one of the tasks performed during Sprint Review. We described that process in detail in this article. Usually, during this meeting, the Scrum Team discusses not only the tasks to complete in the next Sprint. It also preliminarily specifies User Stories and their implementation in the next two or three Sprints. This way of doing things allows the Scrum Team and its activities to take a broader view of the long-term direction. It enables to think of the tasks currently being performed from the perspective of their development in subsequent Sprints.

Errors in Product Backlog maintenance

One of the most common problems regarding the Product Backlog nurturing is allowing it to expand uncontrollably. This is because while working on the Product, various additional functionalities and tasks proposed by both Stakeholders and Scrum Team members spontaneously appear. Therefore, limiting the growth of the Product Backlog scope (scope creep) is one of the most important tasks performed by the Product Owner. The most common mistakes that Product Owners make concern:

1. Deviating from the Product Objective – adding too many ideas to the Product Backlog beyond the basic Product Objective is not a good practice, as it greatly reduces its readability. It works better to collect ideas for additional functionality in a separate document.
2. Duplication of content – entering repeated or very similar ideas from different Stakeholders into the Backlog – before adding another entry to the Backlog, the Product Owner should make sure that the new entry does not duplicate any of the existing ones.
3. Lack of a broader perspective – you should order Product Backlog entries according to their value concerning the Product Goal. Still, keep in mind that prioritization should take into account the next several Sprints so that the tasks performed in a given Sprint are seamlessly linked to both the preceding Sprint and the Sprint immediately following it

You cannot avoid mistakes of this kind. However, awareness of their occurrence can make the Product Owner more cautious about adding new User Stories to the Product Backlog to work out the right balance. This is because it is also a mistake to give the Backlog too much cut and eliminate entries that contain similar tasks that differ. For example, describing similar Product functionalities that differ significantly in the application.

Backlog maintenance vs. metrics used in Scrum

The Product Backlog contains a description of the remaining work throughout the project. However, only an up-to-date and regularly nurtured Backlog can accurately estimate the ratio of the amount of work completed to the total. To depict the amount of work completed, you should apply the Burndown Chart, which we wrote about in this article.

Another popular metric to describe Scrum Team work is Velocity. You can measure it by comparing the number of Product Backlog entries converted into Increment during a single Sprint. We described Velocity in more detail in this article.

Summary

The Product Owner performs Product Backlog Nurturing. When the Product Backlog is well maintained, the Scrum Team has a clear view of the work that remains. It can also get a broader, forward-looking perspective of what the path to the Product Goal looks like. This is why the Product Owner needs to make sure that the User Stories included in the Product Backlog are in order of priority for completion. And also that the tasks to complete in the upcoming Sprints are described in the finest detail.

If you like our content, join our busy bees community on

Common mistakes during a Sprint Retrospective – table of contents:

1. Introduction
2. Insufficient transparency
3. Focus on one-time problems or successes
4. Over-representation of Product Owner
5. Self-management problems
6. Too many commitments
7. Common mistakes during a Sprint Retrospective – Summary

Introduction

Mistakes during a Sprint Retrospective are unfortunately very common. This is because it is one of the most difficult meetings to successfully execute as it requires a lot of maturity from the team. That’s why it’s worth taking a look at the problems that occur most often in other teams so that you can more easily spot their symptoms when conducting Sprint Retrospective in your Scrum Team.

Insufficient transparency

According to the Scrum Guide, each member of the Scrum Team is obliged to be honest and bold in expressing concerns and to voice their opinion during the Sprint Retrospective. However, in practice, the commitment to transparency is very demanding. Because of this, Scrum Team members often try to circumvent it.

One problem that is difficult to spot and solve is avoiding discussion of observed shortcomings in the Scrum Team’s work. This can lead to much more serious problems in the long run.

The Scrum Master’s task, therefore, is to keep a close eye on the situation in the team and encourage all team members to be proactive from the very beginning of the Sprint Retrospective.

Focus on one-time problems or successes

Another problem that can arise during Sprint Retrospective is paying insufficient attention to cyclical and repetitive team behaviors, and their impact on team effectiveness.

It’s always good to congratulate Scrum Team members if they have achieved exceptional success. However, Sprint Review should not be dedicated to celebrating it. The same is true of failures. If something failed due to fortuitous reasons or an already diagnosed error, it is not worth over-analyzing the event during Sprint Review.

Sometimes, however, the team devotes a large part of the Sprint Retrospective to such events. Keep in mind though, that the purpose of Sprint Retrospective is to look for ways to improve the team’s daily work. Therefore, the meeting should not revolve around one-time successes or problems that are highly likely not to happen again.

Over-representation of Product Owner

In many organizations, the position of Product Owner is equated with that of Product Manager. Product Owner is then often considered the supervisor of the Scrum Team. For this reason, it happens that the Development Team does not want to talk about teamwork problems in his presence.

That is why it is so important to build mutual trust between the Development Team and the Product Owner. Unfortunately, the process of building trust is difficult and lengthy. That’s why sometimes it’s a good idea for the Product Owner to give up participation in all or part of the Sprint Retrospective to leave space for the rest of the team to discuss freely.

Self-management problems

Self-management means that Scrum Team members make their own decisions about who among them will perform certain tasks, when and how. During Sprint Retrospective, the team discusses people, their interactions as well as team practices. It then decides what problems need to solve in the upcoming Sprint, how to do it together with who will bear responsibility for taking action.

If more serious problems arise in a self-managing team, there may be a temptation in the Scrum Team to abdicate responsibility.

Occasionally, team members don’t want to take part in the discussion and try to push the management responsibility onto someone else. To prevent this, it is extremely important to discuss even small problems regularly to prevent their accumulation.

Too many commitments

An active Scrum Team operating following the three pillars of empiricism: transparency, inspection and adaptation, may encounter the problem of making too many commitments at once.

If the commitments made by the Scrum Team during a Sprint Retrospective are too many, there is a considerable risk that:

• none of the commitments will be implemented properly
• some commitments will not be implemented at all
• the changes made will not be permanent

Therefore, a good practice is to undertake no more than four improvements in each Sprint. This allows for a gradual but effective improvement of the team’s performance.

Common mistakes during a Sprint Retrospective – Summary

Since Sprint Retrospective is a challenging event, problems often arise during its conduct. To deal with them more easily, it is worth noting the ones that arise most often. Common mistakes during a Sprint Retrospective are:

• insufficient transparency – when Scrum Team members fail to deal with honesty in more difficult team situations
• focus on one-off problems or successes – when Scrum Team members focus on discussing successes and failures, instead of discussing the long-term effectiveness of the team’s work
• Product Owner over-representation – when Scrum Team members treat the Product Owner with limited trust as if he or she were someone outside the team or a supervisor
• self-management problems – when Scrum Team members try to shift responsibility for problems and decision-making.

If you like our content, join our busy bees community on

What is a Sprint Retrospective? – table of contents:

1. Introduction
2. Objectives and topics of Sprint Retrospective
3. How to conduct an effective Sprint Retrospective?
4. Problems to be discussed
5. Discussion and commitment
6. Summary

Introduction

Sprint Retrospective is the meeting that ends each Sprint. It is one of the Scrum Events, which we wrote about in an overview in a separate article.

According to the official Scrum Guide, a Sprint Retrospective takes a maximum of three hours for a monthly Sprint. Or correspondingly shorter if the Scrum Team works in shorter cycles.

Objectives and topics of Sprint Retrospective

All members of the Scrum Team take part in the Sprint Retrospective. The purpose of the meeting is to discuss problems related to the Scrum Team’s work and how it handles them. However, these are not problems related to the Product being developed by the Scrum Team, but issues related to the nature and course of cooperation between Scrum Team members.

Because the issues raised are often sensitive and touchy, the Sprint Retrospective is a closed event. We can formulate its objectives in the following way:

• to summarize the current ways of cooperation
• to identify those problems and imperfections that require improvement
• to suggest solutions and modifications

The goals of Sprint Retrospective are closely related to the pillars of empiricism on which Scrum is supported. The first two points are related to inspection. While the last one is related to adaptation. We wrote more about the pillars of empiricism and their role in Scrum in this article.

The result of the answers to the above meetings is not only a clear picture of the Scrum Team’s principles of cooperation available to all its members. The Team also makes commitments to improve cooperation and team behavior, which will be implemented in the next Sprint.

How to conduct an effective Sprint Retrospective?

Because the Sprint Retrospective is a difficult meeting, the role of the Scrum Master who moderates the discussion is crucial. Ideally, he or she should suggest to the Scrum Team members to speak next. For example, he can ask everyone to give a one-sentence summary of the ending Sprint.

Problems to be discussed

Since talking about problems in the team can stir up a lot of emotion, a common solution is to write down the issues to be discussed on separate pieces of paper. This makes it easier to express your opinion. It’s also easier to spot larger problem areas and issues that more people have concerns about.

If there are too many issues that Scrum Team puts forth, you can start by discussing the major ones. Or select collectively which issues are the most important in the opinion of the Scrum Team.

You can postpone problems for which there was not enough time during the Sprint Retrospective to the next retrospective. Of course, only in case they still occur.

Discussion and commitment

The most important parts of the Sprint Retrospective, however, are discussion and making commitments.

The discussion should focus on the causes of the problems, the moments when they occur, and their impact on the functioning of the Scrum Team. It is worth considering whether their occurrence can be avoided and with whom to discuss their solution.

Making commitments is just as important as diagnosing the problems because just knowing they exist and the causes do not translate into solving them. The result of a Sprint Retrospective is usually several commitments. If the problem affects the whole team, often one of the team members is committed to paying special attention to a particular problem in the next Sprint. And to propose its solution, or even to solve the problem itself. If, on the other hand, the problem concerns the action of a specific person, he or she commits to change his or her behavior as early as the next Sprint.

Summary

Sprint Retrospective is a summary of a Sprint from the perspective of collaboration between Scrum Team members. Its purpose is to improve efficiency and nurture the three pillars of empiricism: transparency, inspection and adaptation. Transparency, whereby all collaborators talk frankly with each other about both successes and problems that arise in the team. Inspection, which involves the frequent and reliable diagnosis of the situation in the team, and adaptation, i.e. correcting errors that arise on an ongoing basis.

If you like our content, join our busy bees community on

Sprint Review – table of contents:

1. Introduction
2. The role of Stakeholders during Sprint Review
3. Releasing Increments
4. Working on the Product Backlog during Sprint Review
5. Summary

Introduction

Sprint Review and Sprint Retrospective are two Sprint Summary Events. In this article we wrote more extensively about the roles that each Scrum Event plays. Today, we’ll just mention that they provide an opportunity to ground the three pillars of empiricism – transparency, inspection, and adaptation – concerning the Product and the work of the Scrum Team.

Sprint Review is dedicated to the Product. And its purpose is to inspect the Increment, i.e. the results of the work done in the Sprint that just ended. The event lasts a maximum of four hours. All members of the Scrum Team, as well as Stakeholders, i.e. all people interested in the progress of the Product attend it.

The role of Stakeholders during Sprint Review

During the Sprint Review, the Scrum Team presents the Increment to the Stakeholders. In doing so, it summarizes the completed tasks and answers specific questions:

1. Who performed the task?
2. What specifically was done?
3. For what purpose was it done?

The Stakeholders provide feedback to the Scrum Team members. This allows for adaptation, i.e. adjusting the Scrum Team’s way of working to the needs and vision of the Customer. This is done to maximize the business value of the Product. The feedback provided at each Sprint Review is particularly important when creating innovative products that need to be adapted on an ongoing basis to the activities of the competition and the needs of the market.

Releasing Increments

We shouldn’t consider Sprint Review as the only time the Scrum Team releases an Increment to the Customer. If some Product functionality meets the Definition of Done beforehand, the Product Owner may decide to release it immediately.

It is also possible that an item of the Product Backlog that the Scrum Team worked on in a given Sprint has not been completed and does not meet the Definition of Done. It cannot then get released or even presented during Sprint Review.

Working on the Product Backlog during Sprint Review

Updating the Product Backlog is as much a part of Sprint Review as presenting the work results to Stakeholders. Usually, the Backlog update is dedicated to the last part of the meeting, so Stakeholders do not have to attend.

The Product Owner updates the Product Backlog based on feedback from Stakeholders and lessons learned by the Development Team. This is especially crucial if the feedback obtained has an impact on the shape and Purpose of the next Sprint. Updating the Backlog is then an essential step to preparing the next Sprint Planning.

Sprint Review – summary

Sprint Review is a meeting of the Scrum Team with Stakeholders, during which the results of the Product work obtained in the last Sprint are presented. Its key part is a discussion with Stakeholders, during which they give feedback on the Product. Thanks to this conversation, it is possible to effectively adapt and possibly correct the direction of work on the Product following market requirements. Thanks to the discussions with Stakeholders held at the end of each Sprint, the chances of maximizing the business value of the Product developed by the Scrum Team increase.

If you like our content, join our busy bees community on

Sprint Planning – table of contents:

1. Introduction
2. What is the new Sprint Goal?
3. What is on the agenda?
4. How will the do team do it?
5. The results of Sprint Planning
6. Summary

Introduction

Sprint Planning is one of the Scrum Events that we wrote about in a separate article. This event centers around the User Stories placed at the very top of the Product Backlog. In other words, on those that are most detailed.

Let’s take a closer look at the answers to the questions we’ve just put forth.

What is the new Sprint Goal?

The role of the Product Owner during Sprint Planning is to present the Goal and the tasks comprising it to the meeting participants.

The Product Owner starts the meeting by formulating the Sprint Goal and justifying why it is valuable from the customer’s point of view. Then opens a discussion in which not only Scrum Team members, but also Stakeholders can voice their opinion.

To sum up, the Product Owner gives the final wording of the Sprint Goal that the entire Scrum Team will strive to achieve and makes sure that the Goal is understood by all stakeholders.

What is on the agenda?

The second part of Sprint Planning focuses on selecting the User Stories to implement in the new Sprint and discussing how to make them more specific.

One of the most difficult tasks during Sprint Planning is to accurately estimate the number and labor intensity of the tasks selected for execution. The more experienced the Scrum Team, the more accurate it can estimate how much work can be done in a single Sprint. This is because the Team is applying effective estimation techniques, which we wrote about in detail in previous articles and here. Many Scrum Teams know and utilize methods to speed up the maturation of the Team as well as make the process easier and more standardized. These techniques include primarily Planning Poker and Team Estimation games.

How will the do team do it?

The third and most technical part of Sprint Planning focuses on answering the question “How will the team do it?”. In it, the Development Team proposes ways to accomplish the tasks selected for implementation in the second part of the meeting. No one but the Developers themselves should dictate how the tasks should be executed from the technical side.

Planning should take into account not only the execution technology but also the workflow between Developers. This will avoid stagnant work [bottlenecks], which can cause delays in the execution of tasks. As in the case of how to execute tasks, the distribution of tasks among individual Developers is also decided by them alone without external interference.

Typically, the Development Team here focuses on dividing User Stories into smaller tasks. The optimal length of task execution is one working day.

The results of Sprint Planning

The result of Sprint Planning is an unambiguous Sprint Goal, as well as detailed User Stories selected for execution from the Product Backlog. All these elements make up the Sprint Backlog, which we have devoted a separate article to.

Summary

Sprint Planning is the Scrum event that starts each Sprint. The Scrum Team can invite Stakeholders and external experts to it.

During Sprint Planning, the Goal of the new Sprint is defined. The Development Team determines with the Product Owner what to do and decides how to accomplish the planned tasks.

The result of Sprint Planning is the Sprint Backlog, which the Developers use to select daily tasks from the queue for execution.

If you like our content, join our busy bees community on

Daily Scrum – table of contents:

1. Introduction
2. The Daily Scrum formula
3. Problems with Daily Scrum and the 5W method
4. Supporting questions
5. 5 Whys
6. Summary

Introduction

Daily Scrum is the shortest and most frequent of the Scrum Events, an overview of which can be found in a separate article. The task of Developers participating in Daily Scrum is to quickly set work goals for the next 24 hours. This way, each of them knows what the others are working on and how they are working towards a common Sprint Goal.

The Daily Scrum formula

There is no one right Daily Scrum formula. Each Development Team develops a meeting format that works for it. However, there is a general framework to make it easier to conduct.

A well-conducted Daily Scrum should allow each participant to answer two questions:

• What is the most important task I will perform today?
• What are the obstacles to accomplishing this task?

However, asking them directly is not a mandatory formula. These are sample questions that define the axis of the meeting. Daily Scrum is intended to improve communication in the Development Team, prioritize tasks and reduce the risk of bottlenecks.

The Daily Scrum is an event equivalent to the Daily Standup in other Agile methods. And it often runs very similarly to it – although the official Scrum Guide does not require Developers to stand during this short Event. Very often its participants simply stand while talking in an informal group.

While it may seem that 15 minutes a day is a lot for discussing daily tasks, practice shows that such a meeting is best for the effectiveness of the Development Team. With frequent and regular updates on goals and commitments, all Developers focus on priority tasks and prioritize smooth team progress over individual results.

Problems with Daily Scrum and the 5W method

One of the problems with Daily Scrum is that Developers drag out the meeting time. If this is the case, it’s a good idea to introduce a policy of writing down on a board – either physical or virtual – problematic issues that are not central to the Daily Scrum but are important to the Team. In this way, it will be possible to return to the problems that were left to be discussed during the informal discussions during the day. And also, if needed, during the Sprint Retrospective, which we will describe in more detail in a separate article.

Another problem that often arises during Daily Scrums is turning them into meetings to summarize the previous day’s work. Developers then focus on discussing the results already achieved. This is not a good practice. Admittedly, the current orientation of Developers on the status of the work leading to the Sprint Goal is very important. However, devoting the Daily Scrum to already completed tasks does not promote efficiency.

Supporting questions

If the Team is not benefiting from the Daily Scrum, the Scrum Master can help Developers identify problems by observing the meeting for answers to the following questions:

5 Whys

After the initial identification of the problem, an effective technique for determining the cause of the problem can be the 5 Why method also called 5 Whys or 5W by Sakichi Toyoda. It involves asking several “Why?” questions in a row. This makes it possible to diagnose the deeper cause of the problem, and thus solve it more easily.

For example, let’s take the last item in the table: the problem arises in the area of commitment to problem-solving by the Development Team. The five questions might look as follows:

1 x WHY?

Q: Why don’t Developers offer different ways to solve problems that arise?

A: Because Developer Harry is always the first to propose one solution.

2 x WHY?

Q: Why is Developer Harry always the first to propose one solution?

A: Because no one else is speaking.

3 x WHY?

Q: Why doesn’t anyone else speak up?

A: Because other Developers have no desire to look for better solutions.

4 x WHY?

Q: Why don’t other Developers feel like looking for better solutions?

A: Because finding solutions requires focus and it is easier to consider Harry’s solution good enough.

5 x WHY?

Q: Why did they consider Harry’s solution good enough?

A: Since they are not rewarded for proposing alternatives, they discussed their plans for today at the beginning of the meeting and are thinking about getting started.

In this case, the problem of lack of commitment to solving problems can be solved by changing the order of the Daily Scrum and starting with this issue. Or coming up with a system for rewarding the best solution, for example, introducing a symbolic reward for the author of the largest number of solutions accepted by the Team in a given Sprint.

Summary

Daily Scrum is a key part of the daily work of the Development Team. However, each Team must work out for itself the optimal formula for this meeting. A well-conducted Daily Scrum allows for the ongoing setting of sub-goals to achieve the Sprint Goal. It also makes it possible to quickly diagnose communication problems and improve cooperation between Developers.

If you like our content, join our busy bees community on

Velocity in Scrum – table of contents:

1. Velocity in Scrum – Introduction
2. Actual and planned velocity
3. Difficulties and risks associated with Velocity in Scrum
4. Summary

Velocity in Scrum – Introduction

Velocity is an optional but popular method to measure the pace of a Scrum Team. This is because an accurately estimated Velocity enables predicting, to a reasonable extent, the time needed to complete a project. However, it is a measure that can only be applied to a given Development Team, which will perform tasks that it has “valued” itself using a familiar unit, such as Story Points, for example.

The Velocity of the Development Team is most often presented in the form of a Velocity Chart. On the X-axis are marked consecutive Sprints. On the Y-axis, on the other hand, we will find the number of Story Points or other corresponding units that were completed in a given Sprint. With the Velocity Chart, the Scrum Team gains a clear view of changes in the pace of its work. If the line marked on the chart is rising, it means that the Team is optimizing its efficiency or reducing the value of Story Points. Both the Scrum Master and Product Owner should therefore carefully follow the line showing the Team’s Velocity.

Actual and planned velocity

The actual Velocity of the Development Team describes the pace of work in the completed Sprint and is calculated at the end of each Sprint. It takes the value of the sum of Story Points for all completed User Stories. The actual Velocity of the Development Team allows you to plan and estimate with some probability the pace of future tasks.

The planned Velocity, on the other hand, is estimated based on an average value of the actual Velocity. It requires the assumption of no change in the Development Team. It is an important internal tool for the Development Team, which, based on it, can assess whether cooperation in the Team is going well and whether the pace of work is being maintained.

Planned Velocity also enables the Product Owner to forecast the execution time of well-defined User Stories scheduled for execution in subsequent Sprints. This enables more efficient nurturing of the Product Backlog, which we wrote about in this article. However, the practice of applying planned Velocity to estimate project durations is not so simple.

Difficulties and risks associated with Velocity in Scrum

Velocity in Scrum is often given too much importance without considering the following factors:

• estimating larger wholes or the entire project – while the Development Team can accurately estimate the number of Story Points to be assigned to a specific task, it is very difficult or impossible to describe larger wholes for future implementation in these units
• changes in the project – any change in the project potentially means a change in the number of Story Points needed to achieve the Product Goal. It may also be that tasks already completed will need to be modified or even not used in the final version of the Product
• unforeseen events – predicting the pace of future projects based on those already completed, that is, translating actual Velocity into Planned Velocity, can result in accurate estimates. However, each project has its peculiarities and an accurate prediction based on history is usually impossible.

Summary

Using Velocity as a metric to evaluate the effectiveness of the Development Team can cause its reliability to degrade. It can also degrade the quality of the estimates, which we wrote about in more detail in this article. After all, to get the best possible results in the metrics, the Development Team may overestimate the labor intensity of tasks to increase Velocity. This is detrimental as the team itself then loses valuable information to make improvements and plan its tasks more accurately.

Velocity in Scrum comes in handy primarily as an internal measure used by the Development Team to evaluate the pace of its work. This is because it allows it to determine how many tasks it is capable of completing during a single Sprint.

Velocity in the hands of the Product Owner becomes a useful tool for estimating the deadline for larger tasks.

However, the biggest risks are associated with using Velocity as a metric for evaluating the Development Team. This is because it can lead to a lowering of its credibility and even a deliberate overestimation of its value to improve the external evaluation of the Scrum Team’s work.

If you like our content, join our busy bees community on

Scrumban and Kanban boards in Scrum – table of contents:

1. Introduction
2. Kanban vs Scrum
3. Kanban Boards in Scrum
4. Scrumban
5. Summary

Introduction

Kanban is a method pioneered in Japan. It originated in the 1950s and was primarily a tool for managing continuous production in such a way as to not create inventories and surpluses, but to process resources on an ongoing basis. In the early 21st century Kanban was adapted to the needs of software development by David J. Anderson.

Kanban vs Scrum

The overall way of working in Kanban differs from Scrum primarily by bringing about a less formal approach. In Kanban, there are not so detailed guidelines on, for example, working in Sprints, roles of Product Owner, Scrum Master and Development Team. This is possible because Kanban focuses on the continuity of tasks such as providing a specific type of service, which are more repeatable and does not require such complex planning.

However, the purpose and ways of working are similar. The goal of Kanban is to deliver the highest quality product to the customer on time. The principles concerning the ways of working common to both methods can be formulated as follows:

1. The work should be smooth and without any downtime – in Scrum, this is achieved by the continuous succession of Sprints, while in Kanban the work is continuous due to the smooth flow of tasks. They form a queue, from which the developers choose (pull) a few tasks to complete.
2. The team should focus only on selected tasks – using Kanban terminology, the team should “reduce work in progress”. In Scrum, the equivalent of this is User Stories chosen from the Product Backlog to put into the Sprint Backlog
3. Progress of tasks should be visible for all people involved – in Kanban they are visualized by boards, which are also often featured in Scrum Teams.

Kanban Boards in Scrum

A Kanban board is a widely used tool for visualizing teamwork. It is a table with several columns. In each of them, there are tasks with a certain status. Categorization of tasks is based on a simple rule: a card with a description of the task – or its virtual equivalent – is placed in one of the columns. The minimum version of Kanban boards contains three columns:

• To do
• In progress
• Completed – to the last column go the tasks that meet the Definition of Completion, about which we wrote here.

Below you can find an example of a kanban board from an all-in-one project management system – ¿­·¢k8Æì½¢Ìü.com

Commonly, there are more columns. If there are more tasks to complete, there is usually an additional column titled “selected for completion” between the “to be completed” and “in progress” columns. While the “to-do” column serves as the Product Backlog, which we wrote about here, the “selected for completion” column serves as the Sprint Backlog, which we describe in detail in this article.

The second common addition is an “under review” column or “for approval”. It is usually inserted between the columns containing the “in progress” tasks and the “completed” ones. It contains tasks completed by the Development Team that is waiting for approval from the Product Owner. The Product Owner’s task is to check their compliance with the acceptance criteria and get their final approval from the Customer. In this situation, only the finally accepted tasks are moved to the last column.

Scrumban

Due to the huge popularity of Scrum and Kanban, their hybrid appeared, combining the best of both ways of working. Scrumban works best in organizations that connect the creation of Products with the provision of services, often involving the implementation of the Product at the Customer. Because of the reduction in meetings and communication, the Team can be larger.

Scrumban places less emphasis on metrics commonly used in Scrum, such as the Burndown Chart. However, it uses the Scrum pillars of the need for continuous improvement of the work process and adapting them to the customer’s conditions and needs.

When working in Scrumban, however, the work is not divided into Sprints. Scrum meetings are held every 3, 6, or 12 months.

Scheduling of work follows the “On-Demand” principle, i.e. as it occurs. User Stories are placed directly in the first column of the Kanban board containing “to-do” tasks. Thus, it serves as the Sprint Backlog, which we wrote about in more detail in this article. As in the Sprint Backlog, the most urgent tasks are placed at the top of the to-do list. However, for more complex projects, the Project Manager can maintain a separate to-do list corresponding to the Product Backlog, from which he or she selects which tasks to place in the first column.

When moving tasks from the first to the second column, the “Pull” rule applies. It means that tasks are not delegated to a particular Developer. Each person chooses a task from the queue and executes it independently.

The number of tasks placed in the middle column, “to complete” is usually limited depending on the size of the team, so that, if possible, everyone deals with only one task at a time.

Summary

Scrum and Kanban, although used for similar purposes, are different ways of working. Scrum works best in creative, innovative projects done by small Scrum Teams. Kanban, on the other hand, was created to operate in a continuous and downtime-free environment to provide similar services. Scrum often uses Kanban boards as a method to visualize the work being done. The combination of both resulted in Scrumban, which works best as a framework for organizations that sell their products and provide services based on them to the customer.

If you like our content, join our busy bees community on

Advantages and disadvantages of the Burndown Chart – table of contents:

1. Introduction
2. Advantages of the Burndown Chart
3. Disadvantages of the Burndown Chart
4. Summary

Introduction

We have written about what it is, how to create and interpret a Burndown Chart in previous articles. Today we will focus on the advantages and disadvantages of the Burndown Chartt. However, most of them are not hidden in the simple graph itself. Rather, they are related to the ways of using the Burndown Chart to motivate the Development Team, as they describe the results of their work and strengthen self-organization.

Advantages of the Burndown Chart

The Burndown Chart allows you to visualize the progress of your project. Its readability and simplicity make it so popular. That’s why it’s a good idea for the Burndown Chart to be not only a constantly updated metric hidden in a digital project management tool. If at all possible, it’s worth making it a reference point for the Development Team visible in the physical workplace. Whether in the form of an on-screen visualization or a hand-drawn sketch.

It motivates the Development Team

The transparency of the Burndown Chart can make it a tool to motivate the Development Team to work efficiently. Reaching the “zero” point in each Sprint can become an ambitious goal of the Team, for which rewards are given – according to the principles of business gamification.

The visibility of an up-to-date and interestingly maintained Burndown Chart can also enhance a spirit of cooperation and self-organization. After all, the metric is a measure of teamwork. It doesn’t show exactly who did – or didn’t – complete the planned tasks, only the results achieved.

It measures the actual work performed

Developers decide how many tasks they will perform in a given Sprint. The more experienced the Team is, the more accurately they should predict their actions. And the bur-down chart reflects the real progress of the Sprint.

Thus, the advantage of the Burndown Chart is not so much to measure the objective amount of work done, but the ratio of planned-to-completed tasks. Thus, Developers gradually learn how to plan them and can estimate their capabilities more and more accurately and eliminate repetitive errors.

It couples with other tools

One of the significant advantages of theBurndown Chart concerns its versatility in combining with other tools. The following tools can apply to:

• analyzing the work of the Development Team
• visualizing the progress of work on the Product
• estimating the project budget

For example, in the latter case, the use of the Project Scale Burndown Chart allows for a comparison of the planned and actual budget for the entire project.

Disadvantages of the Burndown Chart

Despite all the advantages of the Burndown Chart outlined above, it can become a source of confusion for the Development Team. However, what we frequently call the “flaws” of the Burndown Chart are not due to imperfections of the tool itself. The problems outlined below concern the way of implementing the Burndown Chart rather than its design. Below are the flaws that can interfere with depicting the progress of the Development Team in this way.

“The Human Factor”

Charts cannot be an absolute measure of a team’s progress. They are just tools to apply in different, more or less skillful ways. We can consider it as a disadvantage (or advantage) not only of the Burndown Chart but also of other measures of team performance.

To create a Burndown Chart, you need other people to enter data. In other words, the Developers put down task completion time on the chart. They might have lengthened or shortened it a bit – either through inattention or wanting to make things better for the team. Developers also sometimes forget to log their time. Or leave the timer on. This causes the working time to extend to several hours. And after discovering the mistake, it is difficult to reconstruct its real course.

Changes to the Sprint Backlog

Sprint Backlog should not be modified after the start of a Sprint. However, in practice, such changes occur quite often. They result from changing requirements of Stakeholders. Or unforeseen problems that Developers encounter.

This causes the Burndown Chart to be scaled. This is because the time taken to complete the tasks remains the same. However, the scale of tasks remaining increases. This may give a misleading impression that the Development Team has incorrectly planned the work to do in a given Sprint. Or that it works too slowly.

Changes to the Sprint Backlog can also result from tasks that were scheduled for completion too quickly. In such a situation, the Development Team usually decides to increase the number of tasks. This in turn may result in not completing them on time. Also, conflicts may arise from the overlap of remaining tasks from the previous Sprint with new tasks scheduled to be completed by Stakeholders and Product Owners.

Changes to the Product Backlog

Big changes in the Product Backlog can disrupt the shape of the Burndown Chart. And thus strongly falsify the picture of work progress and Team effectiveness. This happens when new User Stories appear. And those which are close to the implementation phase are often broken into smaller parts. It also happens that the Client resigns from some Product functionalities.

Therefore, when interpreting the Burndown Chart, one must be guided by knowledge and experience in evaluating the Team’s performance. And also take into account the variability of the Backlog. If the chart is not the only metric used to evaluate performance, the other charts will allow you to see a more complete picture of the progress of the work.

Summary

The Burndown Chart can significantly contribute to the motivation of the Development Team. This is because it provides a measure of the real work done on the plan. Moreover, its combination with other metric tools can be a source of valuable knowledge about the Team’s work and Product planning.

By carefully applying Scrum principles, you can avoid potential problems with the Burndown Chart. The most important thing is to adapt the tools of keeping the chart following the actual Scrum Team’s work, as well as to minimize changes to the Sprint and Product Backlog, which we write more about in this article.

If you like our content, join our busy bees community on

How to create and interpret a Burndown Chart? – table of contents:

1. How to create a Burndown Chart?
2. Who is responsible for the Burndown Chart?
3. How to interpret a Burndown Chart?
4. Real and ideal Burndown Chart
5. Selecting the unit of measurement
6. Summary

How to create a Burndown Chart?

The Development Team should monitor its daily work. This is the basis not only for evaluating its effectiveness but also for improving it. And one of the simplest and proven tools for this purpose is the Burndown Chart.

You can create it manually by drawing a coordinate system on a piece of paper. On the Y-axis you need to plot the amount of work expressed in a chosen unit, for example, story points. On the X-axis, draw a scale indicating the consecutive days of the Sprint. Draw a line of the ideal sprint then mark the number of realistically completed tasks for each day. Although this solution is charming and engages the team, it is not very practical. It is also not necessarily suitable for remote teams.

Therefore, digital means of creating a Burndown Chart are much more common. Many tools for logging work on tasks distributed among Team members come with an option to automatically create a Burndown Chart. Then, all a Developer has to do is mark the start and end of work on a particular product feature, and their contribution is reflected in the Burndown Chart.

With the right tools, it is also possible to freely scale the chart. This gives an insight into the combustion not only on the level of a given Sprint but also on the scale of a quarter or the whole project.

An important factor to consider when choosing a tool for creating a Burndown Chart is its accessibility to all Scrum Team members. The visibility of the Burndown Chart to the entire Development Team is a key motivational factor. Equally important is a daily look at the line showing the work remaining to be done. Talking about burn-in during the Daily Scrum,, gets Developers thinking about the ways they work and the current state of the Product.

Who is responsible for the Burndown Chart?

The question of ownership of the Burndown Chart is somewhat controversial. On one hand, it should belong to the Scrum Master, because it is a tool to make sure that the Team is working efficiently and according to plan. On the other, it should remain in the hands of the Product Owner, because it reflects the progress towards a Product Goal that’s communicated to the Customer. What’s more, a third party to claim its ownership is the Development Team as the chart functions as its internal tool.

The Burndown Chart is an essential metric to evaluate the effectiveness of the Development Team and becomes adopted by all Scrum Team members. That’s why transparency and accessibility are crucial. However, its very purpose is to serve the Team. It is supposed to strengthen its self-organization, improve motivation, and give a real picture of the status of work on the tasks assigned to it. Therefore, in theory, each member of the Development Team can update the Burndown Chart.

In practice, however, the task of updating the Burndown Chart usually falls to the Scrum Master. This happens especially at the beginning of his work with a new Development Team when the Team Velocity is still variable and difficult to estimate. Nevertheless, it is recommended to delegate this task to one of the Developers. After all, the chart is meant to be an honest and internal measurement of the progress of the work as judged by the Developers themselves.

How to interpret a Burndown Chart?

We described the appearance of the Burndown Chart in detail in a previous article. Here we will only remind you that the X-axis shows the time left to complete the work. On the other hand, the Y-axis shows the amount of work remaining to be done.

Real and ideal Burndown Chart

To interpret a Burndown Chartt, the key factor is not only the regular plotting of the real “combustion”, i.e. the execution of tasks by the Development Team. Equally important for the picture is its comparison with the ideal combustion line drop (guideline).

By comparing the ideal burn line with the real-world reduction in work marked on the Burndown Chart, two very important parameters can be assessed. First, to see whether the work continues at the current pace, the Development Team will meet the Sprint Goal or Product Goal on time. Second, to get an idea of when the work will be completed while maintaining the current pace. In other words, the Burndown Chart shows the actual pace of the tasks, and the ideal line shows at what pace the Team should work to complete the tasks.

The Burndown Chart also allows you to determine a value called Development Team Velocity in the long run. We will devote a separate article to it. Here we will just mention that it is a value determined by the amount of work done during one Sprint.

Thanks to the fact that the Burndown Chart illustrates the comparison of an ideal burn line with a real decrease in the number of tasks, it allows you to estimate the pace of work. And thus anticipate the risk of project delays.

Selecting the unit of measurement

Team velocity is usually measured in units called story points. It defines the number of user stories that have been realized. These can require very different amounts of work.

This is why many Scrum Teams use a time-based measure. Depending on the scale, these are days or man-hours. Each Developer estimates and then logs the amount of time spent on their tasks.

Another option is to adopt tasks as a unit. These are slightly larger units, which in turn are assigned a value expressed in story points, or in days or man-hours. It is a unit that allows the client to present the progress of work on the product in a clearer way.

Regardless of the unit of measurement, it is worth remembering the principle of calculating the speed of the Development Team. In a given day or Sprint, only tasks that were actually completed, count. It means that tasks started will be counted towards the next day or Sprint even if only final testing is missing.

Summary

With the team monitoring tools available, creating a Burndown Chart becomes an easy task. The most important issue is to ensure its coherence, clarity and accessibly to all Scrum Team members.

If you like our content, join our busy bees community on

Scrum Team Commitment – table of contents:

1. Introduction
2. Product Objective
3. Sprint Objective
4. Definition of Completion
5. Summary

Introduction

The Product Goal was not added to the official Scrum Guide until its 2020 version. It is defined there as a Scrum Team commitment to the final shape of the Product. It is made by the Scrum Team and written in the Product Backlog.

The Product Goal thus joined the previously existing Goals in Scrum: The Sprint Goal, which is about the Sprint Backlog, and the Definition of Completion, which is the Scrum Team’s commitment to delivering the Increment according to agreed-upon guidelines.

The creators of Scrum thus decided to make the following connections:

Committing is designed to strengthen the Scrum Team’s focus. It provides the team with a clear goal and horizon for the entire project, one Sprint, and an Increment.

They should all keep in mind the Product Vision and the long-term strategic goal. The Vision is not a commitment of the Scrum Team, but rather the horizon of all its aspirations. It helps in formulating the Goals accordingly. It can be formulated as follows:

Product Vision: To become the world leader in magic commerce and services.

In the text below, examples of sub-goals will refer to this example of the Product Vision.

Product Objective

The Product Goal is a description of the future Product that the Scrum Team is working on from the beginning to the end of the project. The path to achieving the Product Goal is written in the Product Backlog.

A Scrum Team can only do one Product Goal at a time. To change it, the Scrum Team must either complete it or abandon it.

A good formulation of the Product Objective depends on the industry in which the Scrum Team works. But in all cases, the Goal should be compelling, clearly expressed, and relevant. In other words, it should describe the key achievement that brings the Product Vision closer to realization.

It could be, for example:

Product Goal 1: To open the world’s first online store for magic accessories.

Product Goal 2: Create a 24/7 flying broom service.

Sprint Objective

A Sprint Goal is a description of the work that will be done within a Sprint. It is expressed in the form of a Business Objective to ensure consistency in the work of the Development Team. And also increase Focus – one of the core values of Scrum.

The completion of Product Goal 1 that we proposed above could be broken down into the following Sprint Goals:

Sprint Objective 1.1: Conduct a market survey of magicians for demand for magic accessories

Sprint Objective 1.2: Compile a list of suppliers and product availability

Sprint 1.3 goal: To create a store website

Whereas for Product Goal 2, the Sprint Goals could look like the following:

Sprint Objective 2.1: Find a convenient location for the first service point

Sprint 2.2 goal: Conduct service technician recruitment

Sprint 2.3 goal: Launch a local marketing campaign

Each Sprint Goal is defined and discussed by the Scrum Team during Sprint Planning, which we discuss in detail in this article. A Sprint Planning event cannot be completed without defining the Goal for the next Sprint.

Definition of Completion

The Definition of Completion is another detailed commitment made by the Scrum Team. Unlike Product and Sprint Goals, it is formal by definition.

It usually consists of a list of quality criteria that must be met by the Product for the Increment to be considered finished. Thanks to the Definition of Completion, Scrum Team members and each Stakeholder can easily see what changes and improvements have been made to the Product by a given Increment.

For Sprint Objective 1.1: Survey the mage market for demand for magic accessories, a criterion for the Increment could be: Compile survey results of mages active in the magic forum. The definition for completing this increment could be as follows:

Definition of Incremental Completion 1.1:

• Each of the magicians gave comprehensive answers to the questions
• At least 80% of magicians are active
• The results of the study were entered into a magic bullet database

The definition of completion can also refer to quality standards defined by the organization. Then it is not freely set by the Scrum Team. Its minimum requirements are set by the external requirements of the organization.

However, the Definition of Completion differs from the acceptance criteria we wrote about in the text on User Stories. Referring to the example of Completion Definition 1.1, the acceptance criteria could be formulated as follows:

Acceptance Criterion 1.1:

• Estimate the percentage of magicians who will be willing to use an online store
• Identity which accessories are most popular among them
• Determine what budget your potential customers have

The acceptance criterion, therefore, refers to the performance of the task as it is perceived by the customer.

Scrum Team Commitment – summary

Scrum Team commitments are the Product Goal, Sprint Goal, and Definition of Completion. These enable the Scrum Team to stay focused while working on detailed tasks. They allow the Scrum Team to answer the question of what the key achievement will be from the perspective of the Product Backlog, Sprint Backlog, and Increment.

If you like our content, join our busy bees community on

Burndown Chart – table of contents:

1. What is a burndown chart?
2. What does a burnown chart look like?
3. Estimation of task completion time
4. Summary

What is a Burndown Chart?

A Burndown Chart serves to estimate the time and effort needed to complete a task. It is also a valuable warning tool if the work does not go as planned. With a single glance, each Scrum Team member is able to assess the status of the tasks. Therefore, the Burndown Chart should be easily accessible to everyone involved in the project.

The Burndown Chart in Scrum features in two versions: as a Sprint Burndown Chart and as a Project Burndown Chart. We will discuss them together because the principle behind them is identical. They differ only in the time scale and the number of tasks they depict.

What does a Burndown Chart look like?

On the Burndown Chart, the X-axis shows the time remaining to complete the work. If the chart is for a Sprint, the time is measured in days. On the other hand, if the Burndown Chart is for an entire project, time is usually measured in Sprints.

The Y-axis of the Burndown Chart indicates the amount of work remaining. Thus, it refers to the tasks included in the Sprint Backlog or the Product Backlog. The units used on the vertical axis of the chart can be:

• Story Points – which you can read more about in the text on User stories
• Man Days/Hours
• Tasks

The Burndown Chart typically includes a burn-down line that represents a perfect, linear decrease in the number of tasks that remain to be completed. It provides an outlook on the projected completion time.



Estimation of task completion time

Each Developer individually needs to estimate the number of hours they need to complete a particular task. And the estimated time to complete a Sprint Goal or Project is the sum of time estimated by all Developers. The immense difficulty is to translate the estimated time into the actual time of task execution. This is one of the major problems newly formed Development Teams face It can distort the picture presented on the Burndown Chart.

Moreover, it is not always possible to create an optimal workflow in a Development Team. As a result, task execution may suffer from downtime, which increases the task completion time.

One of the indicators of Team maturity is the ability to accurately estimate the work time. The more predictable, the more mature the team is. This is reflected in the burn rate graph, where the line reflecting real burn rate descends steadily to zero. However, this formulation does not apply to all situations.

As we wrote in the article about the statistics monitored by Scrum Master, much depends on the nature of the project itself: its innovation and the repetitiveness of the tasks performed by the Developers. The burndown chart works best for projects where the scope of work is fixed and known. Therefore, in case of innovative projects it is better to use other ways of measuring team effectiveness.



Summary

The Burndown Chart works well as a basic progress metric for most Development Teams. It is a tool to visualize the workload and time required to achieve a Sprint Goal or Product Goal. Because of its clarity and accessibility, the Burndown Chart allows all Scrum Team members to assess, in real time, where the project work is at.

If you like our content, join our busy bees community on

]]> /burndown-chart/feed 0