R¶

The reference configuration is a defined state of a product at a specific point in time. It serves as a starting point for further steps in the project.

A reference object is a previously planned or executed project that is so similar to the current project that conclusions can be drawn about the workload and methodology.

In the systems-theoretical context, relationships refer to how individual elements of a system, such as in the project structure plan, interact with each other. Goals can be related to each other in different ways, such as supporting or excluding each other.

A release burn-down chart is a graphical representation predicting the progress of a project release. It shows the remaining work compared to the remaining time.

Release planning involves planning for the completion and delivery of a project. This planning becomes possible once the PBIs in the Product Backlog are consistent, and the velocity of the Developers is known.

A report is a document containing information on a specific topic or period and is addressed to specific recipients. It serves communication within the project and to external stakeholders.

Report formats refer to predefined document structures that regulate the content and form of reports.

Report types are a collective term for different forms and obligations regarding reporting in a project. Reports can, for example, be dependent on a specific time or event.

Reporting duty refers to the obligation to send reports with specified content to specific recipients at certain deadlines.

Reporting obligation refers to the obligation to send reports with specified content to specific recipients at certain deadlines.

Reporting system deals with target group-oriented and needs-based information distribution to all project participants, serving the control and documentation of the project.

The repressive approach means that decisions are made and implemented without the involvement of those affected, often as a "fait accompli."

Requirements in Scrum can be formulated as user stories, features or use cases, etc.

Requirements analysis is the process of identifying the specific needs and requirements of a project. This usually takes place in the initial phase of a project and is particularly relevant in software development.

The requirements specification serves as a contract between the customer and the supplier. It lists all the requirements that the customer has for the project.

Reserve time is the part of the buffer time that is allocated to an activity as a disruption reserve in addition to the working time when the deadline is set. Reserve times can also be scheduled as waiting times in the network from the outset.

Resource autonomy describes the authority over the human and material resources needed for the project. Control over personnel and materials is particularly high when resources are specifically reserved for a project.

Resource management in project management is concerned with the effective planning, allocation and control of available resources such as labour, time, materials and equipment. The aim is to ensure that the required resources are available at the right time and in sufficient quantity to successfully achieve the project's objectives. It also involves balancing resources between different projects to avoid bottlenecks.

Ressource levelling refers to a procedure in resource planning where tasks are adjusted so that the demand for resources is evenly distributed over time.

Ressource limitation is a method of resource planning where tasks are planned or stretched to ensure that available resources are not exceeded.

The retrospective is an essential process at the end of a project phase or an entire project. It is a structured discussion or analysis in which the project team collectively reflects on the activities performed, the results achieved, the challenges faced and the lessons learned. The aim of a retrospective is to gain insights for future projects, reinforce best practices and identify potential improvements in processes and collaboration. In the agile project management framework Scrum, the retrospective has its own place called the Sprint Retrospective. This is where the challenges and positive trends in team collaboration during the previous sprint are examined in more detail, and improvements for the upcoming sprint are outlined.

A review meeting, also referred to as a retrospective meeting, is a regular gathering in project management where the team presents the progress of a completed work section or a project milestone to stakeholders. The aim is to present achieved results, gather feedback from stakeholders, and discuss potential adjustments for future phases. In Scrum, the review meeting is related to the past Sprint and is called the Sprint Review – in contrast to the Sprint Retrospective, this meeting focuses on examining the product more closely.

Risk analysis is a process where potential risks are identified, assessed, and prioritised. It involves analysing the probability and impact of risks to develop strategies for minimising or coping with these risks. This helps project management be prepared for possible problems early on.

Risk exclusion refers to contractual agreements on risk distribution between contracting parties, such as liability sharing or insurance.

Risk management includes the identification, assessment, and control of project risks. The goal is to minimise negative impacts and promote positive opportunities.

Risks in project management can be treated differently: risk avoidance, risk reduction, risk limitation, risk transfer, and risk acceptance.

The risk value, also known as risk potential or risk factor, is the assessment of a risk based on the possible damage (monetary) and the probability of occurrence [%].

Risks are potential events with negative impacts on the project. They can jeopardise project progress or goal achievement.

Role assignment within the team involves deciding who takes on which tasks and who serves as a contact person for specific questions or problems.

Roles in Scrum are specific positions in the Scrum Team: The Product Owner is responsible for the Product Backlog and the value of the product, the Scrum Master promotes Scrum principles and supports the team, and the Developers work on the technical implementation.