AGILE FRAMEWORK: SCRUM¶

Unlike traditional project management, in Scrum, extensive and detailled planning documentation is mostly not needed. At the beginning of a project there is a Product Goal, which is aimed to be implemented. Based on this goal, a collection of requirements for the product is created in the form of a one-dimensional, prioritised backlog, the Product Backlog. Now, the incremental implementation begins. This process centres on short development cycles, so-called Sprints. Within these cycles, continous value is added to the product, and every newly developed deliverable can afterwards be reviewed by the customer or a responsible representative, as well as by the stakeholders. This allows the correction of expensive undesirable developments at an early stage of the project and thus avoids escalating time losses and additional costs. To ensure a smooth workflow, Scrum has certain rules (the empirical Scrum pillars of transparency, inspection, and adaptation) and values (commitment, focus, openness, respect and courage), which all participants commit to.

The Scrum project map¶

Scrum Roles¶

The three main roles¶

In contrast to traditional project management, there is no project manager in Scrum. Instead, a Scrum Team consists of a Product Owner, a Scrum Master and Developers. They work together to create the best possible product.

The Product Owner is the customer or the customer's full representative in the project (proxy). He ensures that the customer's ideas are reflected in the project and he is responsible for the return on investment (ROI).

Developers are a cross-functional team of people who work autonomously and are responsible for making their own decisions regarding the product development. They are committed to generating added value in every Sprint.

They are supported by the Scrum Master as a coach and team developer who, among other things, takes care of optimising the work environment and promoting Scrum in the company (as defined in the Scrum Guide). He is responsible for the effectiveness of the Scrum Team by eliminating organisational obstacles and impediments to the workflow [14][15][16].

The application of Scrum in project management can look quite different, such as:

• A company needs a new software or a new application and commissions a development company for this purpose
• Within a company, the individual departments need to ajust their software needed for working and commission the IT department
• A company implements a new enterprise resource planning (ERP) system and commissions several Scrum Teams to develop applications

Members of a Scrum Team can also be distributed over large distances, so the roles Product Owner, Scrum Master and Developer are not always within the same company. This means that the conditions, as outlined in the Scrum Framework, cannot always be adhered to, so that the roles, responsibilities and processes can vary. Under certain circumstances, however, this can negatively affect the work results.

The goal of Scrum is to develop workable and potentially shippable results (e.g. software, etc.) through so-called Increments.

Product Owner¶

The Product Owner has the objective to increase the value of the product and is also solely responsible for this. He is always an approachable person, neither a department nor a committee. As manager of the Product Backlog, his remit includes:

• Responsible for the (potentially shippable) added value of the product
  (Return on investment - ROI)
• Develops and communicates the Product Goal
• Responsible for creating the entries of the Product Backlog, if necessary in the form of user stories
• Prioritises and clearly communicates these entries
• Represents stakeholders in different scenarios (e.g. customers and users) and is responsible for stakeholder management
• Develops the Sprint Goal together with the Developers
• Is (ideally) available for the Developers during the Sprint to answer any potential question
• Responsible for the inspection of the Increments
• Has the authority to decide whether the Sprint should be continued or terminated

NOTE: The Product Owner may carry out the tasks related to the Product Goal and the Product Backlog by himself or by delegating them to others. Nevertheless, he is solely responsible for the outcome.

Developer¶

The developers are the people in the Scrum Team producing usable Increments in each Sprint. They are self-organised and all technical skills should be represented as much as possible. The tasks of the Developers include:

• Creation of the Sprint Backlog (planning basis for each Sprint) and negotiation with the Product Owner on the amount of work to be done
• Shared responsibility of the results of each Sprint
• Deliver value and quality through adherence to a "Definition of Done" (DoD)

In addition, the team of Developers is

• interdisciplinary (cross-functional),
• (self-)responsible for the implementation of the tasks and
• ideally consisting of 10 members or less.

Scrum Master¶

The Scrum Master is responsible for promoting and living Scrum as a framework. He ensures that all people involved understand and follow the principles, procedures, rules and values. The Scrum Master's task is to fulfil his agile leadership role as a servant leader [17]. That means, he foceses on facilitating, empowering and thus coaching others so that they can act successfully in the sense of Scrum. His success depends on their success. Beside the Product Owner and the Developers, he is also the contact person for the company and an integral part of the Scrum Team.

In relation to the Product Owner, he ensures that everyone involved within the Scrum Team also understands the Product Owner's task horizon. This includes the goals and also the product domain. Furthermore, his area of responsibility includes:

• Assisting the Product Owner in formulating the Product Goal, defining Product Backlog items and, if necessary, the user stories
• Support at all Scrum meetings
• Assistance with prioritising entries
• Support and, if necessary, coaching on how to practice and live agility and empirical approaches
• Promoting collaboration with stakeholders (faciliate), if desired

Regarding the Developers, his task is to support the team in all matters and to develop it into a successful team (see performing team). This includes the following tasks:

• Coaching the team to become a performing team
• Supporting the self-organisation of the Developers, so that they can make and carry out decisions on their own
• Promoting (interdisciplinary) cooperation
• Ensuring that all Scrum events take place in an orderly manner (adherence to the time frame, positive and productive working environment)
• Identification of impediments and ensuring their elimination
• If necessary: mediation between Developers and Product Owner

With regard to the organisation, it also depends on the degree to which Scrum as a framework with its requirements and processes is already established in the company. How hierarchically is the company organised and to what extent can responsibility be effectively delegated? Is there already an understanding of this and is it therefore also possible to enable agile, empirical and incremental procedures? Especially when introducing Scrum, this can mean encountering resistance and reservations. The corporate culture also plays a decisive role. Mainly, the Scrum Master enables the following in the company:

• Communicating the procedure, goals, context and mindset for agile approaches
• He is an organisational developer and takes care of the implementation of Scrum in the company, so that the framework conditions are given or, if necessary, improved
• Information and coaching of employees, line managers, responsible persons
• Assisting all employees and stakeholders in understanding agility as well as empiricism (role as agile leader)
• Reducing barriers between stakeholders and the Scrum Team

Role assignment in large-scale Scrum projects (Scrum of Scrums)¶

In large-scale Scrum projects, it may be necessary or possible to have several teams of Developers working simultaneously [18][19]. In this case, a Scrum Master may be able to supervise several teams at the same time. It is different with the Product Owner, because here each team is assigned a specific Product Owner designated for each "sub-project". In this constellation, however, it is important to identify a Chief Product Owner who then has overall responsibility and final decision-making authority over the other Product Owners.

Responsibilities¶

Product Vision¶

The overall goal¶

The Product Vision sets out the overall goal for the development of new products. The period or horizon goes far beyond the completion of the individual project and includes the product life cycle [20]. The aim is to formulate the desired economic success as a vision and to pursue the question of how it can be achieved. This is the responsibility of the Product Owner. However, it does not necessarily have to be worked out in all cases, for example when Scrum projects are carried out within a company (e.g. the IT department develops applications for specialist departments).

It should be noted, as of 2020, the Product Vision no longer exists as such. Instead, the Product Goal has taken its place [21]. The Product Vision can be understood as a larger Product Goal and can also be used to define an overarching goal.

Commitment: Product Goal¶

The development compass¶

The Product Goal is the Scrum Team's commitment to the Product Backlog and serves as a compass for the development of the current project. Unlike (previously) the Product Vision, it describes a concrete goal that is pursued with the Scrum project and generated by the Sprints [22].

Customers and users should be involved as much as possible in the development of the Product Goal. The Product Owner develops a common understanding of the goal for the stakeholders of the project and defines the framework conditions that serve the marketing of the product and its economic success.

This involves the following questions:

• Why is the project being carried out?
• Which audience is to be addressed?
• What is the need or benefit of the client/ consumer?
• What is the project about? What exactly is being offered?
• What are the unique selling points of the application or product compared to competitors?
• How is the business model structured?
• In which way is profit to be generated?

Scrum Artifacts: Product Backlog¶

Requirements list¶

The Product Backlog is created at the beginning of each Scrum project after the Product Goal is set-up. It is a central collection of all product requirements and is managed by the Product Owner.

It contains every entry that is necessary for the development of the final product. These entries are also called Product Backlog Items. They include features, functions, requirements, but also corrections, representations, or even user interfaces (Graphical User Interface) [23].

A frequently used form of entry are so-called user stories [24]. User stories are short descriptions of product features from the user's perspective that are written by the Product Owner or the stakeholders. They don't make any reference to how the features are to be technically implemented - this comes later in the Sprint Backlog.

Once the initial set of requirements has been identified, the next step is to prioritise the entries in the Product Backlog, i.e. to rank them according to their importance. Entries listed higher up in the Product Backlog are more detailed and precise than entries listed lower down [25]. The top entries are therefore those that the Product Owner wants to have implemented first. The criterion for prioritisation is usually the business value contribution that the implementation of the respective user story delivers. But other criteria can also play a role, such as development costs or risks [26]. In each Sprint (development cycle), a number of the top entries from the Product Backlog, determined by the Developers, are converted into an Increment.

To do so, the Items or user stories listed higher up must be defined in such a way that their implementation is possible within the short Sprint cycles.

Further down in the Product Backlog there are entries of various sizes: additional entries, user stories, Epics (very extensive user stories) and Themes (user stories that are grouped together in a common topic area).

As soon as these entries are moved to the upper area of the Product Backlog, they have to be broken down into smaller entries or user stories to ensure their feasibility.

When the Developers commit to a user story, it is taken out of the Product Backlog and the other user stories move up a place. Tasks that meet the "Definition of Ready" and align to the Sprint Goal are ready to be moved to the Sprint Backlog [27].

The Product Backlog changes continuously.

Backlog entries have a description, are classified and estimated. If necessary, test descriptions are added; these belong to the acceptance criteria, which in turn are part of the "Definition of Done".

The Product Backlog

• is the responsibility of the Product Owner.
• contains a list of the desired functionalities.
• may contain user stories as an essential component.
• contains entries that are prioritised and estimated (e.g. business value contribution, importance). Top-priority entries will be processed in the next Sprint.
• is refined during the project, if there is reason to do so, according to the Product Owner's specifications.
• is subject to constant change and is the centre of agile adaptation.
• should meet the DEEP criteria (detailed appropriately, estimated, emergent, prioritised).

Backlog Refinement¶

Backlog Grooming or Backlog Refinement Meeting¶

In the Backlog Refinement Meeting, existing entries in the Product Backlog are reviewed and prioritised. During this meeting, the contents are further specified and their effort is estimated.

New entries are derived from the previous results of the implementation. The prioritisation is then updated due to changing boundary conditions and PBIs or user stories that have been identified as unimportant for the product are removed from the Product Backlog [28].

During the preparation for the next Sprint, those Product Backlog Items that are to be processed are selected and the activities for their technical implementation are planned. This preparation is usually carried out in Sprint Planning.

Following topics can be used as an agenda for the Backlog Grooming Meeting:

• Sorting and prioritising the Product Backlog Items
• Deleting entries that are no longer important
• Adding new entries to the Product Backlog
• Formulating and adding details to Product Backlog Items
• Summarising Product Backlog Items
• Estimating entries in the Product Backlog (effort estimation)
• If necessary, schedule releases

User Stories¶

Items in the Product Backlog¶

An important factor in the creation and design of the Product Backlog is the customer's or end user's perspective on the product. User stories give the actual user the opportunity to express what they want in their own language. Therefore, the entries are created in the form of user stories and entered into the Product Backlog. While the technical implementation of the requirements was still entered in the Product Backlog when Scrum was introduced, this is now largely dispensed with. Technical aspects and matters relating to implementation are entered in the Sprint Backlog (see Sprint Backlog).

A user story is written from the user's point of view and contains information about "role", " function" and "business value", i.e. benefit or added value [29]. This ensures that everyone involved in the project - such as customers, end users or other stakeholders - can express their wishes without having technical knowledge or having to express themselves in technical terms.

For a user story to be implementable (if it meets the "Definition of Ready"), it should comply with the INVEST criteria [30]:

Independent
Negotiable
Valuable
Estimable
Short
Testable

Furthermore, when adding user stories to the Product Backlog, the three Cs for good user stories should be taken into account. The Cs stand for Card, Conversation and Confirmation [31].

Card:
The most important details of a user story are recorded on a card. This includes the priority of the user story, its acceptance criteria and also the amount of work required to implement a user story, which was determined via estimation.

Conversation:
Product Owner and Developer have discussed the user story in depth and the outcome of the user story was understood by all.

Confirmation:
Acceptance criteria are defined for the Product Owner's acceptance tests confirming implementation of the user story in an Increment.

Updating the Product Backlog¶

The Product Backlog should be evaluated and reviewed at regular intervals. This assessment allows the entries in the Product Backlog to be revised and checked to see whether they are still up to date and whether they correctly reflect the customer's interests. The Backlog Refinement Meeting is suitable for updating the Product Backlog.

It is important to always have a sufficient number of user stories defined as "ready". The "Definition of Ready" status refers to Product Backlog Items that meet the three Cs and the INVEST criteria as well as being sufficiently small and detailed for conversion into tasks (see Definition of Ready). This means that they can be adopted at any time during Sprint Planning and subsequently added to the Sprint.

Definition of Ready (DoR)¶

The "Definition of Ready" (DoR) indicates that tasks or user stories listed at the top of the Product Backlog must be described in such a way that they are understood by the Developers and can be implemented in the next Sprint.

If Product Backlog Items (PBI) do not comply with the DoR and the Developers have not understood them exactly, the development effort may increase and the processing of the items may exceed the time frame of the Sprint. In the worst case, this leads to a missed Sprint Goal or an Increment not being delivered on time [32].

In other words, a task is considered as "ready" when the Developers say they have understood it. Only when the PBIs meet the DoR, the INVEST criteria and the three Cs, they are ready for implementation and thus can be transferred to the Sprint Backlog.

Properties of PBIs that fulfil the "Definition of Ready" can be [33]:

• Clear and comprehensible for every Developer
• As small as possible (fine granular)
• Estimated and offer added value
• At least one acceptance criterion (which is understood by all concerned)

Agile Estimation¶

Estimating work effort¶

Estimating the work effort necessary to implement user stories in the Product Backlog is a crucial aspect of agile project planning. It gives the Scrum Team an idea of the total scope of work over the course of the project.

No specific estimates, such as work effort in terms of working hours, are made. The objective of backlog estimating is to look at the backlog items in relation to one another. Product Backlog estimates make it easier to adapt release plans to changes that affect velocity and to assess the impacts of these changes.

Agile estimation procedure:

• The team uses a method such as "planning poker" to do the estimate.
• Each entry in the Product Backlog is estimated. Start with the user story that is expected to require the least amount of work.
• Then all further entries are compared with the first entry and evaluated relatively to it.
• The amount of work is usually estimated in story points.
• The Fibonacci scale is recommended for estimating story points:
  Fibonacci's number sequence is obtained by adding the preceding number to the following number (1, 2, 3, 5, 8, 13, 21, 34). Items at the top end of the sequence are epics and will have to be split into multiple user stories.
• Another method is to compare user stories to dress sizes, i.e. XXS, XS, S, M, L, XL and XXL. Items at the bottom end of the scale are epics and will have to be split into multiple user stories.

Sprinting¶

The creation of project deliverables¶

Sprints are development cycles in which the project deliverable is produced. They are carried out in fixed intervals of a maximum of four weeks or less [34][35]. The time periods can be changed if the Scrum Team decides so. For complex development projects, shorter Sprints are recommended, as this way action can be taken more quickly if the project is not progressing in the right direction. During the Sprint, a Sprint Backlog (Scrum task board) is used, which is updated daily. The Sprint Backlog is positioned in the work area (or virtually) so that all members of the team can see it and keep up to date on the precise status of the Sprint.

Scrum Artifact: The Increment¶

A step towards the Product Goal¶

The goal of every Sprint is to deliver a tested, usable and sometimes even a marketable product. Each Increment is a step towards the Product Goal. However, any deliverables that do not meet the Definition of Done are not considered an Increment.

The Increments created are accepted by the Product Owner in the Sprint Review at the end of the Sprint as well as reviewed by him and other present stakeholders together with the Developers [36][37]. It is also possible to deliver an Increment to the stakeholders before the end of the Sprint.

The final product, which is described by the Product Goal and specified in the Product Backlog, is the sum of all Increments.

Commitment: Definition of Done (DoD)¶

When is an Increment complete?¶

The Definition of Done (DoD) is the commitment associated with the Increment. It is an important agile tool that helps teams plan and execute work. In principle, the DoD is simply a set of criteria that the product must meet in order to be considered as done.

An essential aspect of Sprinting is the demand that a Sprint is only considered successful if all user stories have been fully transformed into an Increment and then presented in the Sprint Review. Even if not all Stories have been implemented, the Sprint Review can be defined as "Done" if the Sprint Goal has been met [38][39][40].

The DoD criteria that all implemented user stories within an Increment must meet, may include the following requirements: business, functional, quality and non-functional requirements [41]. They can also be defined by the Developers after consultation with the Product Owner.

Examples of "Definition of Done" criteria:

• The Sprint Goal has been achieved according to the Scrum Team's evaluation (this may also be the case if not all user stories have been implemented).
• The acceptance criteria of the implemented user stories are fulfilled.
• The release documentation has been completed.
• The Increment has been tested.
• Existing guidelines, standards and norms have been complied with.

Scrum Artifacts: Sprint Backlog¶

What are we doing next?¶

At the beginning of each Sprint, the items from the Product Backlog, which are to be processed in the coming Sprint, are selected and converted into a shippable (= tested, demonstrable) Increment. During the Sprint Planning Meeting, the Product Owner, if applicable the Scrum Master and the Developers participate in the selection process [42][43]. The Developers decide how many entries are to be processed in the upcoming Sprint and orient themselves on the velocity achieved in the previous Sprints. In addition to the Product Backlog Items and the Increments, the Sprint Backlog consists of the Sprint Goal.

It has proven useful to have a task board [44] positioned in the development area where everyone can see it showing the Sprint Backlog. The user stories are listed in order of priority in the left-hand column. The column to the right of the user stories contains a to-do list of tasks associated with each user story within the Increment. These tasks are defined by the Developers in the Sprint Planning Meeting. The next column lists work in progress (WIP), and the last one lists tasks that have been done. This ensures that everyone can see the current status of all the tasks. If the Developers are distributed across different locations, it's a good idea to use a software-based Sprint Backlog.

The Sprint Backlog:

• Is a list of entries that are to be processed in the current Sprint.
• Its entries are taken from the Product Backlog.
• Is a description of the technical measures (tasks) for implementation (e.g. design, architecture, programming, testing and refactoring).
• Is the responsibility of the Scrum Team, whereby the Product Owner formulates the Sprint Goal and the Developers make a forecast of the functionalities that are to be developed.
• Is placed in the working area for everybody to see. Maintenance and updating is done in time for the Daily Scrum (daily stand-up meeting).

Commitment: Sprint Goal¶

The purpose of the Sprint¶

The Sprint Goal is another commitment of the Developers to the Sprint Backlog. It gives the Developers a framework and guidelines for the upcoming Sprint. The Sprint Goal is developed during the Sprint Planning Meeting and should encourage the Scrum Team to work together. After the goal has been created, it is included in the Sprint Backlog and serves as a benchmark for the Developers. If during the Sprint the results do not meet the Sprint Goal, the Developers can renegotiate the focus of the Sprint with the Product Owner if necessary. However, the Sprint Goal may not be changed during the Sprint.

Sprint Planning¶

What will be done in the upcoming Sprint and why is this an added value for the product?¶

Sprint Planning is a meeting to select the entries from the Product Backlog for the next Sprint. In the case of more complicated user stories or Epics, it may be advisable to hold a two-part Sprint Planning Meeting in which the Product Backlog is checked and prioritised and the entries to be considered for the next Sprint are split up if necessary and discussed in detail. In this meeting, the Scrum Team also focuses on the Sprint Goal that is to be achieved in the Sprint.

Basically, there are three topics that are dealt with during Sprint Planning:

• Why is this Sprint valuable?
• What can be accomplished in this Sprint?
• How should the selected tasks be completed?

After this preparation, the Developers can then focus on the implementation of the user stories into tasks in the follow-up meeting.

The number of user stories selected for implementation in Sprint Planning is based on two criteria:

On the one hand, the net working time which is available and, on the other hand, the estimated task working hours which were estimated for the realisation of the user stories. Here, however, one can also orientate oneself on the story points achieved in the estimation workshop.

Both pools of hours should be roughly equal in order to have a realistic chance of completing the tasks on time.

With increasing project duration and the experience gained, the user stories (story points) for the Sprint can also be selected on the basis of the teams' velocity.

The selection of the user stories for the Sprint is finally determined by the Product Owner. By the end of the Sprint Planning Meeting, the developers mutually agree to achieve the defined Sprint Goal, i.e. the implementation of all selected user stories, if possible.

• Participants: Scrum Team and eventually representatives of the customer or the end user
• Duration: maximum of 2 hours per Sprint week
• Facilitation: Scrum Master
• Responsible for the objectives: Product Owner
• Result: Sprint Goal description and Sprint Backlog for the upcoming Sprint

Daily Scrum¶

The 15-minute stand-up meeting¶

The Daily Scrum is a fixed stand-up meeting during the Sprint in which the Developers briefly inform each other about their progress on a daily basis, ideally at the same time and place [45][46]. If necessary, the Scrum Master ensures that the timetable, the duration and the constructive process are adhered to.

Agenda:

Usually, it is up to the Developers to decide how this meeting should be organised. However, it has become common practice for each Developer to briefly give his or her team colleagues three pieces of information:

1. What have I done yesterday?
2. What do I intend to achieve today?
3. What impediments are disrupting my workflow?

Any impediments that are raised at the Daily Scrum meeting have to be resolved as quickly as possible by the Scrum Master. An impediment backlog may be used to document the impediments and their resolution.

• Duration: 15 minutes, stand-up meeting
• In the Developer's responsibility
• Participants: Developers and, if applicable, Scrum Master
• Ideally in the morning with compulsory attendance and punctual appearance of all Developers
• Result: Information about the current progress, improved communication, rapid initiation of improvements, as well as an increase in the mutual knowledge of all Developers

Scrum Chart: Sprint burndown chart¶

Sprint tracking tool¶

The Sprint burndown chart shows which tasks still have to be done as well as the Developers progress within the Sprint. Each workday the estimated work effort required to perform the remaining tasks is entered in the chart and checked against the pre-plotted ideal burndown line. If the team doesn't have enough working hours remaining in the Sprint to complete all the tasks, the number of tasks in the next Sprint is reduced. Vice-versa, if there is time left over at the end of the Sprint, the number of tasks is increased. A Sprint burnup chart is another alternative. This is an upward trending chart comparing the amount of work completed against the total amount of work. The Sprint burndown charts, like the Sprint Backlog, should be displayed well visible in the working area.

Sprint Review¶

Inspection of the Increments of this Sprint¶

The Sprint Review is held at the end of each Sprint and has the purpose of reviewing the achievements of the Sprint and determining future adjustments.

In this meeting, the Scrum Team presents the results of the Sprint to the stakeholders. Here, the Increments are reviewed and the progress towards the Product Goal is discussed. The project environment is then analysed for any changes and, if necessary, adjustments are made to the Product Backlog. The results of the meeting give the Developers feedback on the finished work and ensure that information is provided for subsequent steps [48].

Tasks or user stories that have not been completed by the time of the Sprint Review or that contain errors as well as entries that are not accepted by the Product Owner are returned to the Product Backlog. Then they are reprioritised and, if necessary, completed in the next Sprint. Entries that are defective or marked as "technical debt" are either implemented immediately or identified as a Backlog Item and processed according to the urgency and degree of criticality.

NOTE: The Sprint Review is a collaborative meeting, not a mere presentation.

Sprint Review

• Participants: Scrum Team and stakeholders, customers if applicable
• Duration: maximum of 1 hour per Sprint week
• Result: Product Owner determines, whether the Sprint Goal has been achieved, live demonstration of the Increments and feedback from stakeholders and Product Owner

Technical Debt¶

Consequences of poor technical implementation¶

In software development, the term "technical debt" is a metaphor for missing or incomplete work or for poor-quality technical implementations. Entries in the Product Backlog with a technical debt are often characterised by the fact that improvements to the defective product require more time and planning effort.

For further planning, it must be taken into account that an increasing technical debt of each new Increment leads to a significant increase in the complexity of the product and, as a consequence, the velocity is reduced.

In general, a distinction can be made between prudent and reckless or deliberate and accidental technical debts. Those for example are caused by communication errors, insufficient technical knowledge or inadequate quality assurance of the processes. However, technical debts can also occur due to pressure from management or during the parallel development of new features (additional work at interfaces) [49].

Examples of a technical debt can be:

• Deferring of documentation
• Lack of development standards
• Failure to back up data
• Delay or incorrect implementation of automated tests
• Failure to make corrections
• Disregard of programming standards (e.g. anti-patterns) or warnings (e.g. compiler warnings)
• Incorrect definition or implementation of software architecture

Sprint Retrospective¶

Lessons-learned and continuous improvement process (CIP)¶

The Sprint Retrospective primarily serves the Developers to improve their productivity and the processes, but the entire Scrum Team can also be the target of this measure as well. The meeting is held after the Sprint Review and before the next Planning Meeting.

In this meeting, the past Sprint is assessed to ensure that the process ran as smoothly as possible and to determine what can be improved for future Sprints [50][51][52].

• Participants: Scrum Team
• Moderation: Scrum Master
• Duration: Maximum of 3 hours
• Result: Reflection on the previous Sprint and clarification of how it went and whether there is room for improvement.

The following agenda can be used (plus-delta method):

• Acknowledgement of the agenda by vote (hand signals)
• Creation of a timeline of the past Sprint with post-it stickers.
• Subsequent marking of specific points on the timeline with plus and delta cards.
• Discussion of the results of these markings
• Identification of changes and improvements to be made, or the elimination of impediments for the next Sprint (infrastructure, external interference attempts, improvements to the performance of the Developers, etc.)
• Identification of action items, people responsible and deadlines for completion

Velocity¶

The amount of work done in a Sprint¶

The velocity sums up the story points of the user stories that a team of Developers has implemented in a Sprint per Increment [53][54]. Assuming that team composition and Sprint length remain unchanged, a new value for the velocity is obtained after each Sprint. Averaged, these values result in a decisive variable that can be used to produce release burndown charts and a release plan. The velocity depends on the project, the tasks processed and the Developers - it can therefore only be transferred to other projects to a limited extent.

Release Planning¶

On basis of the Product Backlog¶

At the beginning of an agile project, scheduling is in many cases only possible to a limited extent:

• The Product Backlog consists of many items that are subjective and usually have to be adapted to a large extent.
• During the course of the project, new entries are added, older entries may prove to be obsolete and are deleted.
• The velocity of the Developers to implement the PBIs is not known at the beginning of the project and may have to be estimated.

The sum of all estimated Product Backlog Items only allows precise release planning as soon as the velocity of the Developers is known. If it is a newly formed team or the first time a Scrum project is carried out in the company, the velocity can only be determined over the course of the project (see velocity).

Scrum Chart: Release burndown chart¶

Release forecasting¶

The release burndown chart can be used to determine the time of the product release as soon as the velocity of the Developers is known or can be well estimated and the total number of entries in the Product Backlog required for the release is more or less stable.

An ideal burndown line can be plotted for the story points to be completed in a release and the velocity (number of story points expected to be completed in the Sprint) showing the projected release date as the point of intersection between the ideal line and the x axis.

This makes it possible to estimate after which Sprint a release is possible. If it turns out that the deadline cannot be met due to too many entries in the Product Backlog (or due to lower velocity than planned), the number of entries must be reduced in order to keep to the deadline.

Release burndown chart:

• The chart is created on the basis of the user story estimates made at the outset of the project
• Y axis: the total work to be completed in story points (total of all points for release-relevant user stories in the Product Backlog)
• X axis: number of Sprints

Meetings in Scrum¶

Meetings in Scrum take place in a fixed sequence. They are also time boxed, which makes them considerably more effective [55][56]. Time boxed means that all meetings have a specific fixed duration and stop at the end of the timeframe. If issues arise during the meetings that require more detailed discussion, they are clarified in a specially scheduled meeting with the participation of the people affected by those issues.

Participants are expected to arrive punctually and comply with the code of conduct during the meeting (e.g. switch off mobile phones and focus on the topics being discussed).

Time boxed and efficient Scrum meetings¶

Meetings are a regular part of Scrum and should therefore be held before or after each development cycle. All information refers to a 4-week Sprint (monthly Sprint); for shorter Sprints, the duration of the respective meeting is correspondingly shorter.

ATTENTION: The Backlog Grooming Meeting isn't an official Scrum meeting so it isn't time boxed [57][58].