Who Owns the Sprint Backlog of User Stories

What is scrum - A compact introduction to the Scrum method

The Scrum method is a framework for agile product development and agile project management. Despite its origins in software development, Scrum is also enjoying increasing popularity in non-software projects.

In this article I offer you a compact introduction to the Scrum method based on the current Scrum Guide (2020). After a general introduction, I will introduce you to the roles and responsibilities in a Scrum team, Scrum meetings and activities and the most important Scrum artifacts.

What is scrum - Scrum definition, history and principles

Scrum is a rugby term and literally means “arranged scrum”. The two Scrum founders Jeff Sutherland and Ken Schwaber presented the Scrum method to the public for the first time in 1995 at a conference. Since then, the Scrum method has been continuously developed and has contributed significantly to today's understanding of agile working methods. The two Scrum fathers were also significantly involved in formulating the agile manifesto in 2001.

Scrum definition

If you want to answer the question “What is Scrum” in a nutshell, then I find the following Scrum definition appropriate.

Scrum is a framework for teamwork based on a definition of roles, meetings and tools that give a team structure and a clearly defined work process based on agile principles.

Scrum is not a dogmatic method, but a framework that offers a team and participating stakeholders guidelines and orientation points for their cooperation and communication. The Scrum method is constantly being further developed by www.scrum.org and is documented in the current Scrum Guide. The last update of the Scrum Guide took place at the end of 2020.

Scrum principles

Before I outline the structure of the Scrum Framework in detail, I will go into a few essential Scrum principles. Because these essential agile principles and values ​​are the foundation on which agile work in general and Scrum in particular succeed. That means, without an appreciation of these basic guiding principles, you cannot possibly work successfully with the Scrum method.

  • Vision: This means that every Scrum Team follows a long-term goal that serves as an overarching point of reference.
  • Value orientation: Scrum teams measure their results against the value achieved for customers and companies.
  • Transparency: Goals, decisions and upcoming tasks are freely accessible and known to all those involved and stakeholders.
  • Focus: A consistent prioritization of the tasks to be done ensures a high focus.
  • Autonomy: The Scrum Team is an autonomous team that works in a self-determined and self-organized manner.
  • Process compliance: The Scrum process is not negotiable. Because the process gives a team security, reduces overhead costs through a high level of standardization and at the same time contributes to a high level of transparency.
  • Feedback: Customers, users and stakeholders are closely and regularly involved in the Scrum process and contribute to continuous improvement with their feedback. In addition, the Scrum Team improves its collaboration through regular retrospectives.

Structure of the Scrum Framework

The Scrum Framework is essentially based on three central cornerstones:

Scrum roles - responsibilities of the people involved:

Scrum meetings and recurring activities:

Scrum artifacts, tools and important Scrum terms:

Part 1: Scrum roles - Product Owner, Developers, Scrum Master

Product Owner (PO) - 1 person

The Product Owner (PO) or Project Owner has the task of maximizing the value from the product or project. To do this, he balances the interests of the company (business value) and the users / customers (user value). The PO formulates and communicates a long-term vision for the project. In order for this to be successful, the PO needs a thorough understanding of customer needs and the strategic framework from the company's point of view.

The most important tool of the product owner is the backlog and the prioritization of the topics it contains. In this way, the PO ensures that the team is working on the right tasks and that everyone in the team uses their time profitably in the interests of the company and the customer. In addition, the product owner formulates a “sprint goal” and superordinate “product goals” for each sprint.

In this advanced article of the #DNO you will find the tasks and the ideal competence profile of the product owner.

Developers - 3 to 8 people

With the Scrum Guide 2020, the development team simply became the role of the developer ”. This simply means the implementing team, which works autonomously and in a self-organized manner on the implementation of the agreed tasks. To do this, the team is committed to the tasks to be completed in a sprint. This means that no work packages are assigned by the PO or any other person. Instead, the team decides during the planning which of the prioritized tasks can be completed as part of the sprint. In order for teams to be self-effective and to be able to commit themselves to tasks, an important prerequisite is that development or project teams are interdisciplinary. This means that all the necessary skills and abilities are available in the team to solve the agreed tasks and to achieve the goals of the sprint.

Scrum Master - 1 person

The Scrum Master is the coach of the team and the product owner. That is, his most important task is to enable the team and the product owner to do their job in the best possible way. He removes obstacles, contributes to efficient implementation and supports the team in adhering to the Scrum process. In addition, the Scrum Master protects the team from unwanted influence. He also coaches the stakeholders involved and ensures that agile principles are lived by all those involved.

Part 2: Scrum Process - Sprints and Scrum Meetings

The second important cornerstone of the Scrum Framework is the Scrum process consisting of a recurring sequence of sprints. Each sprint is in turn characterized by clearly defined Scrum meetings. This clear structure and, above all, the standardization of the Scrum meetings contribute to a high level of efficiency. With the Scrum process you reduce the organizational overhead to an absolute minimum.

In the following I will outline what characterizes a sprint and with which goals and under which rules the Scrum meetings take place.

Sprint - 1 to 4 weeks

The sprint is the highest central ordering principle in the Scrum Framework. A sprint is a clearly defined time interval in which the team works on completing the agreed tasks and achieving the sprint goal. Sprints literally go hand in hand. That is, the end of one sprint is the beginning of the next sprint. The duration of a sprint is typically 1-4 weeks and is determined depending on the product / project. You should consider the following framework conditions:

  • TheSprint duration is fixed, i.e. all sprints have the same duration. This applies until you determine that a different sprint duration would be more appropriate for your project. Then you change the sprint duration and stick with it.
  • Sprints last a maximum of four weeks. The relatively short cycle of four weeks is due to the insight that the longer a cycle length, the lower the quality of the planning. This realization is also known as the “cone of uncertainty”.

What do the PO and team do during the sprint?

The executive team works on the implementation of the agreed tasks. Since the PO does not participate in the implementation, he has the important task of maintaining and prioritizing the backlog during the sprint and thus preparing the next sprint again. To this end, he also coordinates with the team in refinement meetings so that tasks in the next planning are already thought through and not completely new. He is also available to the team during the implementation for queries or re-prioritizes tasks if new findings arise in the course of implementation that disrupt the original planning.

Cancellation of a sprint

If the originally formulated sprint goal is no longer relevant, has become obsolete or no longer promises any value, the PO can decide to cancel the sprint. Alternatively, the PO can decide that the tasks with the highest priority should be drawn from the backlog.

Scrum meetings

Each sprint is structured through a sequence of scrum meetings. Every meeting has a clear place in the sprint. This includes a clearly defined goal and a regulated timebox that is based on the length of the sprint. All of this contributes to a very efficient and good meeting culture.

First, I'll give you a brief overview and summary of the Scrum Meetings. In the following sections I will go into more detail about the goals and the process of the Scrum Meetings.

EventaimDuration for a four week sprintAttendees
PlanningPlanning the sprint8h, at the start of the sprintPO, developer, optional Scrum Master
DailySynchronization of upcoming tasksDaily for a maximum of 15 minutesDeveloper, optional PO, Scrum Master
ReviewDevelopers present work results4h, at the end of the sprint.Everyone, plus: stakeholders and customers
RetrospectiveOptimizing collaboration3h, at the end of the sprintAll
RefinementClarification and estimation of the backlog items2-4 hours a weekProduct owner, developer, optional Scrum Master

Please note that the times given here refer to a sprint duration of four weeks. In addition, the Scrum Framework is based on the ideal requirement that teams work full-time on implementation. This means that if you do shorter sprints or the team is working on implementation with less capacity, you adjust the length of the Scrum meetings accordingly.

Sprint Planning - start of the sprint, 8 hours

Each sprint starts with a joint planning in which the entire Scrum Team (PO, Developers, Scrum Master) takes part. During the planning, upcoming tasks are discussed and the expected effort is estimated. Only with the estimate of the expected effort is the product owner enabled to make a final decision regarding the prioritization based on the expected benefit and the expected effort. If a task is prioritized, the implementing team is committed to completing the tasks. To do this, the team takes over the prioritized tasks in its sprint backlog. During planning, the product owner formulates a sprint goal. In a four-week sprint in which the team works at 100% capacity, 8 hours are set for sprint planning.

Daily - every day, 15 minutes

The daily is a daily synchronization of the developers or the implementing team. This means that the Scrum Master and the Product Owner only take part optionally. Since the duration is limited to 15 minutes, it often takes place standing up. That is why it is sometimes called the “Daily Stand Up”. Standing and the tight timebox have a very simple background. Because instead of being epic, every team member is invited to give a short update in order to synchronize with their colleagues. Where am I now, do I need help, do I have any other questions? Should there be a need for further discussion, further discussions will take place after the daily instead of bothering the entire team with it during the day. The daily takes place every day at the same time in the same place for 15 minutes.

Sprint review or demo - end of the sprint, 4 hours

At the end of the sprint, the implementing team presents its work results. The product owner, interested stakeholders and customers are invited to this review or demo. This means that the review offers the developers a stage to present their performance in the previous sprint. On the other hand, stakeholders and customers have the opportunity to give feedback and ask questions in order to influence the future planning and prioritization of the product owner. However, the decision as to which of these is prioritized and how is up to the Product Owner alone. This means that the review is not an acceptance test or can be compared with a steering committee. Because here is an autonomous team that has done its best on the basis of joint planning with the product owner. Further tasks are prioritized by the PO. If there is cause for dissatisfaction with the result, this is a topic for the retrospective.

Retrospective - end of the sprint, 3 hours

Finally, the sprint ends with a retrospective by the Scrum Team. The developers, the product owner and the scrum master meet to reflect on the collaboration and, based on these insights, to make binding agreements for future sprints. This means that the retrospective is only about the work process, not about content or work results. The Scrum Master moderates the retrospective, e.g. according to the following pattern.

  • Welcome (“Set the stage”)
  • Gather information and impressions ("Gather data")
    • What went well (Keep)
    • What should we hire? (Drop)
    • What could we try? (Try)
  • Condense insights ("Generate insights")
  • Formulate ToDos for the following sprint ("Decide what to do")
  • Closing - Who do I want to say thank you to?

Agile principles and agile values ​​come into play particularly in the retrospective. Because here you need openness, self-reflection and the desire for constant improvement. The retrospective closes with specific agreements that will be implemented in the next sprint and may also have their own entry in the sprint backlog.

Product backlog refinement

The only Scrum meeting that does not follow a defined structure are refinement meetings. The aim of these refinements is that product owners and developers talk about the scope, outcome and acceptance criteria of upcoming tasks in advance of a sprint planning. This gives the product owner the opportunity to sharpen his requirements and the developers involved the chance to think about requirements. The basic idea is that developers do not only find out about a requirement during planning. This prior synchronization and a common refinement of the tasks are especially important for very complex and extensive tasks in order to ensure the efficient implementation of the planning. So if you notice that you are not getting to the point or coming to a good conclusion during planning, then insufficient refinement could be a possible cause. Refinement shouldn't take more than 5-10% of the time during a sprint.

Part 3: Scrum Artifacts and Tools

In addition to roles and activities, the Scrum artifacts and tools are the third central component of the Scrum Framework. In the following I will briefly explain the following Scrum artifacts.

Product backlog

The backlog is the sum of all upcoming tasks., A suitable German translation would be, for example, “Topic memory”. In other words, in the backlog you will find all the tasks and ideas that you, as the product owner, assume will create value for the project or product or that may only have to be dealt with for formal requirements. The product backlog is maintained and continuously prioritized by the product owner, e.g. in a Kanban board. Ideally, the product backlog can be viewed online for the team and the stakeholders involved.

Product Backlog Items (User Stories)

Individual entries and tasks within the backlog are “Product Backlog Items”. These can be small, very specific ToDos, extensions of existing performance features, new features or even new epics. You always speak of an epic when new performance features have an “epic” breadth or depth and can no longer be implemented within a single sprint. These epics are then broken down into editable Product Backlog Items.

Each product backlog item contains the expected customer benefit, possibly the added value for the company and measurement parameters for assessing the effectiveness of the measures or the feature. In addition, the backlog item contains acceptance criteria that are necessary for the fulfillment of the task. Even if there is no official format for product backlog items, user stories have established themselves as the de facto standard.

Sprint backlog

The sprint backlog contains all tasks that are processed by the developers in the current sprint. While the backlog is under the authority of the PO, the sprint backlog belongs solely to the implementing team. The sprint backlog is a result of sprint planning. Because here the PO and the project team decide together which backlog items will be processed in the coming sprint. If the developers commit to completing a product backlog item, this will be included in the sprint backlog.

Definition of Ready

The Definition of Ready (DoR) is not an official part of the Scrum Guide, but it does reflect an important conceptual idea. Because this is how the team expresses its understanding of the degree of maturity a task in the backlog is allowed to fulfill in order to be processed at all. For example, the expected benefit or measured variables for assessing effectiveness can be part of the definition of ready. If a task does not meet the definition of ready, the PO is required to further develop the product backlog item. Like the Definition of Done (DoD), the Definition of Ready (DoR) is subject to constant adaptation and critical review. For example, during the retrospective, the team can decide to adapt the Definition of Done (DoD) or the Definition of Ready (DoR).

Definition of done

The Definition of Done (DoD) is an agreement and the team's shared understanding of when work is done. This means that the DoD contains general rules for the successful completion of a task. For example, the DoD stipulates that all acceptance criteria must be met in order to complete a task. In addition, a team could e.g. agree that work results must be accessible and discussed for everyone so that a task is really “done”. Accordingly, a task in your Kanban board can only be postponed to “Done” if it meets the conditions of the “Definition of Done”.

Product increment

If you read or listen to the Scrum Guide, the term “Product Increment” is sure to catch your eye. The product increment describes the work results achieved during a sprint. So the “delta” to the work status before the last sprint or the new performance aspects that the team completed in this sprint.

Estimates - Story Points and Planning Poker

During the sprint planning, the implementing team estimates the effort of individual tasks. In this way, the team gives the product owner important feedback on the expected effort of implementation. The PO can therefore directly compare its expected benefit and effort and better prioritize its backlog and the tasks for the sprint. The estimated value that a task receives is also called “story points” based on user stories. If you add up the story points of all tasks in the sprint, you get a measure of the team's performance. This gives you an orientation that will help you to plan better in the long term.

Planning Poker

“Planning Poker” has established itself as a method for estimating. Each team member receives a set of cards that each contain a value from the Fibonacci series (1, 2, 3, 5, 8, 13, 21 ...). After presenting a task, all team members play their card at the same time. This is to avoid team members influencing each other too much. With the card played, each team member estimates the expected relative effort. This is not an absolute estimate of the effort, but the expected effort in relation to a reference task. Because the information associated with the estimate is more important than the absolute effort. That is, if the estimates differ too widely, developers seem to have different understandings of the scope of a task. In this way, planning poker and guessing encourage constructive discussion, raise important questions and help the team to gain a better understanding of the task at hand.

Sprint Goal

The sprint goal describes the goals of the current sprint and is formulated by the product owner during planning. The sprint goal has the important task of providing the developers with an orientation on what is to be achieved in the current sprint.

Product Goal

The “Product Goal” was introduced with the Scrum Guide 2020. The product goal is a cross-sprint goal and is particularly relevant when the results of a single sprint and its “increments” are only intermediate steps for the completion of a new feature. This means that the product goal is also defined over several sprints and offers the team additional orientation beyond a single sprint.

Conclusion - The Scrum method as the father of agile project management

In the meantime, the Scrum model has over 25 years of maturity and constant adaptation behind it. Scrum has become a de facto standard for agile product development and agile project management, especially in connection with Kanban. The appreciation of essential agile values ​​and principles is the foundation on which the Scrum method is effective.

For me as a consultant, Scrum is an indispensable component in setting up an agile project organization for the successful design of digital transformation. And a good and very simple means of shaking the foundations of today's organization a little. If you also want to shake things up a little, you will find a few ideas in this article on how you can introduce Scrum in your organization.

I wish you success.


Further articles:

Working with Andreas: