Have you also read that Scrum is simple but still confused? Perhaps this is due to the Scrum practitioners' extensive use of agreed-upon terms and concepts, which are often not even translated into Danish. This means that it is harder for you to understand the big picture because smaller details muddy the picture.
We have therefore developed this fact sheet, which gives you an insight into the most central terms from the Scrum universe.
If you are a beginner, I would recommend that you read this article first. Here you will find a very basic introduction to Scrum.
In this article, we review the following concepts:
As you may know, Scrum is a so-called iterative process that is made up of a series of Sprints and is based on rapid feedback. That the process is iterative really just means that it consists of a number of elements that are repeated. In this way, the product is gradually developed.
Scrum's gradual, iterative approach replaces the traditional "phases" of the "Waterfall Model", in favor of developing a smaller part of the most important features first, with associated rapid feedback.
Where the Waterfall model assumes that you know all the details of your project from the start, and that very few errors occur along the way, Scrum integrates all development activities in one iteration (a Sprint) and adapts at regular intervals to the changes you may discover along the way.
Scrum has the greatest potential in relation to complex projects that involve knowledge creation and collaboration. Eg. product and software development. Scrum is most often associated with software development, but has also spread to many other areas.
The sprint is the heart of Scrum. A Sprint is a limited period of 2 to 4 weeks duration, during which a "finished", usable and potentially production-ready functionality is created. A new Sprint begins immediately after the end of the previous Sprint.
During the Sprint, no changes may be made that will affect the Sprint's goals.
The composition of the Scrum Team must remain the same throughout the Sprint
The quality objectives must not be reduced
The scope of the project can be clarified and renegotiated between the Product Owner and the team when learning new things.
THE FACTS
The word "scrum" comes from rugby and means "screen scrums". And is what rugby players do when they gather in a clump before running (sprinting) down the field in a group.
Product Owner
Product owner. Is responsible for translating the input, wishes and/or requirements the customer has into a vision for the product and into the product's Product Backlog.
It is the Product Owner's task to identify where the company gets the most value for the Team's work. And prioritize these, with the most important, most valuable features first.
The Scrum Team
Develops the product the Product Owner sets up. The team is self-governing and interdisciplinary and ideally contains all the skills needed to develop a potential finished product. A Scrum Team consists of 7 plus/minus 2 people.
The team creates the product and develops proposals for the Product Owner that can make the product great.
Scrum Master
Focuses on the Scrum process and not on tasks. Has knowledge and experience with Scrum, which he/she uses to help the team with Scrum-related challenges. Facilitates the Scrum process so that it becomes easier for the Team to organize and manage itself.
Ensures that the Scrum Team is successful. Removes e.g. organizational obstacles, facilitates meetings and ensures that the team is not interrupted unnecessarily.
In Scrum, meetings are held at regular intervals to create regularity and to minimize the need for meetings that are not defined in Scrum. The meetings are all time-limited. That way, an appropriate amount of time is spent on planning. All meetings are facilitated by the Scrum Master.
Sprint planning meeting
At this meeting, the Scrum Team and Product Owner plan which tasks or features (Backlog Items) they will try to turn into a potentially functioning product. It is the Product Owner's task to communicate which tasks/features are most important, and the Team's task is to decide how much work they think they can manage to complete during the Sprint. The team "pulls" tasks from the Product Backlog to the Sprint Backlog, where the active tasks are located.
At the end of the meeting, the team divides the selected tasks into a first list of "Sprint Tasks" and finally commits to the tasks.
Daily Scrum and Sprint Execution
A daily meeting of a maximum of 15 minutes. duration during which the Scrum Team reports to each other on progress and obstacles.
Each team member answers the following three questions:
Within Scrum, there are a number of aids, tasks and organizational tools that make it easier to keep track of the many moving parts in a Sprint.
Product Backlog
The first step in Scrum is for the Product Owner to develop a vision for the product. Gradually, this develops into a refined and prioritized list of features. This is called the Product Backlog.
We have already returned the Product Backlog Meeting and if we return to it, we see that the purpose of that meeting is to "make Product Backlog items smaller and more manageable". A Product Backlog thus contains the tasks (items) that must be solved to complete a product.
The Product Owner is responsible for this list, which in priority order, e.g. lists all features, requirements, extensions and bug fixes.
The Product Backlog is:
Product Backlog Item
Each of the tasks on the Product Backlog is called a Product Backlog Item and usually consists of new customer features (making it possible to place a book in the shopping cart), but also development tasks (change the purchase process so that it is scalable), explanatory or research tasks, performance - and safety requirements and any known errors.
Often these are expressed as what are called "user stories", which are precise, clear descriptions of the functionality based on its value for the end user.
Sprint (or Release) Backlog
Consists of the Product Backlog Items that have been selected for the current Sprint. Thus contains the Team's expectation of what functionalities will be in the next Sprint and the work that is necessary to deliver this functionality. That is all the work the Team has identified as necessary to achieve the Sprint's goals.
The Sprint Backlog belongs exclusively to the Team and is constantly evolving.
Often represented by a physical information station. Eg. a board with Post it's.
Sprint Task
Sprint burndown chart
Used to visually show how many working hours are left in a Sprint and whether the Team is involved.
Product/release burndown chart
Corresponds in principle to the Spirit Burndown Chart, but applies here to the entire product.
A very central element in Scrum is that everyone working on the project agrees on when an Item or a Task is finished. So you e.g. avoids having to go back to previous Items because they weren't finished anyway.
Scrum is designed for situations where requirements and/or technology are uncertain.
That is, tasks that people have previously experienced as unmanageable. When deciding whether Scrum is right for you, consider whether the underlying mechanisms are well-defined or whether the work relies on knowledge creation and collaboration. Scrum is, for example, not designed for routine tasks. Also consider whether there is commitment in the organization to create self-organizing teams.
In less unpredictable situations, the procedures described in PMBOK(R).
Daily Scrum is not a place where you discuss, here only debriefing takes place. If something needs to be discussed, this is done at a subsequent meeting.
It is almost always an advantage that the Product Owner participates in the Daily Scrum. On the other hand, it can be a big disadvantage that the Team's boss or others with authority participate, as it can make them feel "under supervision" and under pressure to report big (unrealistic) progress every day.
Sprint Review Meeting
A Sprint Review takes place at the end of each Sprint. Depending on the length of the Sprint, every 14 or 30 days. Here, the previous period is inspected and, if necessary, the Product Backlog is adjusted.
This meeting is used so that the Product Owner and other stakeholders can find out how things are going with the Team (i.e. a look back at the Sprint) and at the same time the Team must find out how things are going with the product and the market. The most important thing about the meeting is therefore an in-depth conversation between the Team and the Product Owner, where everyone is informed about the current situation and receives and receives advice.
The meeting includes a demonstration of what the Team has completed in the past Sprint. However, this demo should not take the form of a "presentation". And therefore no Power Points! In fact, Scrum says that as little time as possible should be spent on this presentation; maximum 2 hours.
Sprint Retrospective Meeting
An important and very central part of Scrum is the ability to continuously inspect and adapt. In the Sprint Retrospective, it is the Team's use of the Scrum framework that is inspected and adapted.
The purpose is to:
Inspect how the Sprint has gone in relation to people, relationships, process and tools.
Identify and fix the major things that went well, as well as possible improvements
Prepare a plan for implementing improvements to how the Scrum Team works.
In this way, the Scrum Master plays a central facilitating role.
Backlog Refinement Meeting
Most Product Backlog 'items' usually need further development (what is sometimes called "grooming"). Typically because they are too big or not understood well enough. Therefore, many Teams find it useful to spend some time in each Sprint preparing the Sprint Backlog before the next Sprint Planning meeting.
Large 'items' are divided and clarified.
Fill out the form to book a 30-60 minute session.
We will respond within 24 hours
Contact us today and hear about your options
