What is a Sprint Backlog in Scrum?

The Sprint Backlog reflects the current project status during a Sprint. The Sprint Backlog contains the schedule and the goal of the Sprint. The goal must be precisely defined, for example, the creation of a QR code or the implementation of a payment service. The tasks or functions to achieve the goal must be defined. The Sprint Backlog is actively worked on and cards are pushed to different columns during the Sprint for example Doing and Done. It can be viewed directly. In the Sprint Planning the Product Owner presents the Sprint Backlog. Each user story contains tasks that are necessary to accomplish the user story. A Scrum Board allows to organize the tasks for a User Story. It can contain three columns like TO DO, DOING OR IN PROGRESS and DONE. Tasks are scheduled for one day. If a task stays in DOING for more than one day (due to too high complexity, blockages or scope) the Scrum team has to work out a solution. Here, the tasks can be further subdivided. The Sprint Backlog is not an unchangeable Scrum artifact, document or list if the achievement of the completion of the increment should also be achieved after a Sprint.

In the Sprint Backlog you have the list of functions or features that should be implemented in the upcoming Sprint. The developers are allowed to decide which features they want to implement in the upcoming sprint. The features or user stories are divided into tasks that can be accomplished daily and are also in the Sprint Backlog. The Sprint Backlog belongs to the developers. The developers are allowed to determine which additional tasks can be added or removed during the Sprint. In the Sprint Back Log is a Product Backlog Item or User Story and is divided into tasks (Tasks) which can be started by a developer (Started Tasks) and mastered (Done).

The Product Backlog Items, Requirements or User Story are elements contained in the Sprint Backlogs. The requirements can be prioritized. Functions should be sorted by risks, dependencies, and deadlines. Functions or requirements should not be dependent on each other.

The organization of the developers' work mostly come from Extreme Programming. It is focused on programming in this project management approach. A method from the extreme programming is the Pair Programming, i.e. a developer writes the code and another developer comments the solution process. The goal is to control each other to minimize errors in the software. Sometimes developers can develop in this way. Another method from Extreme Programming is the Continues Integration and allows the code of each team member to be merged and tested in the team so that the master branch is not destroyed. A Scrum Master can suggest this development approach to Extreme Programming so that work between programmers happens more effectively.

Continues refactoring allows to simplify the code without changing the external functions. It improves the readability, complexity, maintainability and extensibility of the code and system. No perfection is aimed at when refactoring the code so that the costs are commensurate with the benefits.