SCRUM - A Project Management Framework

By Louise Landschoff

If you are seeking knowledge regarding Scrum as a project management framework, this article will give you an overview of Scrum in its essence and how it is related to the project management standards. Since Scrum is a widely used framework, a lot of literature on the topic is to be found. If you want to know more, or already have knowledge of Scrum, seek inspiration in the annotated bibliography that will explain valuable sources for further reading. If you are seeking knowledge regarding pitfalls in the Scrum implementation, take a look at the section 'Pitfalls and Mitigations in Scrum Implementation'. In this section you will also find suggestions of improvement to ensure a successful implementation of the Scrum Framework. This article first include an abstract, then describes the big idea of Scrum, afterwards the application and description of the framework, before pitfalls in the implementation along with mitigations will be described. Lastly, the limitations of Scrum will be listed before the annotated bibliography is presented.

Abstract

In an ever-changing world that is getting more and more complex, the art of project management is becoming harder to control due to uncertainty and the speed in which requirements and demand change. Standard ways of planning a project, such as the Waterfall model, may not be applicable in some cases. To accommodate this issue, the adaptive project management framework, Scrum, can be used because it embraces agility and fast project deliveries. Scrum relates to the project and development life cycles in the PMI standard (p.18-19). Even though Scrum is applicable for both project, program and portfolio management, this article will focus solely on Scrum as a project management framework and the implementation of Scrum.

The Scrum framework was developed in the early 1990's by Ken Schwaber & Jeff Sutherland and is a framework based on empiricism and lean thinking and has its roots in software development (p.1). Today, Scrum is one of the most popular ways of becoming agile and is widely used for various projects. Benefits of utilizing the Scrum Framework to structure the development life cycles are continuous improvements, transparency, early adoption, and embracing change, which is a great advantage compared to the classic Waterfall model(p.16). The process of Scrum is to first create the product backlog and then define the sprint by creating the sprint backlog and then performing development resulting in an increment. By working incrementally, the team can learn from previous sprints to optimize the next and the product may be ready for release earlier than first anticipated. The Scrum Framework creates value in an adaptive and agile way through the Scrum values, the Scrum team, events and artifacts. The values focus on Commitment, Focus, Openness, Respect, and Courage. The team consists of the Product Owner (PO), the Scrum master (SM) and lastly, the self-organizing Development Team (DT). Furthermore, the framework consists of events such as Sprints, Sprint Planning and Sprint Retrospective, and artifacts which are the product backlog, sprint backlog and burndown chart(p.1-12). Scrum has limitations by being non-applicable to 'business-as-usual' projects, constraint of physicality, potential scope creep due to an indefinite end-date etc.

Main idea

As the world emerges, change in demand and uncertainty arise. Being agile and flexible has become a precondition to survive and succeed in today's business environment(p.5). It is crucial for all kinds of businesses to be able to respond and adapt to unforeseen activities and events on the market because if not, someone else will fulfill the customers' demand. Scrum has become one of the most popluar ways of becoming agile(p.15) because it is a simple framework that can be adapted and fulfilled by own needs and goals(p.3). Agility is acknowledged in a few sections in the PMI standard (p. 18-19 and Appendix X3) for being one of the ways of determining the project life cycle in an adaptive manner. Even thought agile is not widely acknowledged in the PMI for now, the work towards incorporating it is underway and extending the practice of project management.

Adaptive life cycles are agile, iterative, or incremental. The detailed scope is defined and approved before the start of an iteration.
Adaptive life cycles are also referred to as agile or change-driven life cycle (The PMI standard, p19)

Agility and Scrum are strong drivers for simplicity in a complex environment especially within the project management knowledge areas; project integration management, scope management, schedule management and risk management(p.23-25) to name a few. For scope and schedule management, Scrum is a strong framework because it is possible to adapt to unforeseen changes as the business environment evolves due to the iterative nature of the framework. For risk management, Scrum is usable based on, again, the iterative nature but also continuous contact to project stakeholders(Appendix X3). This, together with other knowledge areas, all adds up to be a strong framework for excellent integration management throughout the project life cycle.

Scrum theory(p.3) explains how Scrum is based on empiricism, which means that knowledge comes experience and decision making should be based on what is observable, and lean thinking which seeks to eliminate waste and focus on what is value-adding. The empirical pillars of Scrum are transparency, inspection and adaptation(p.3). Scrum improves predictability and the act of controlling risk, which is driven by transparency in the project management process. Having high transparency also implies a need for inspection to ensure progress and identify problems during the process. The inspection process is handled during the Scrum events. Lastly, having inspections without adaptation and learning is pointless which is why the Scrum team must work empirically. Scrum is highly relevant in today's vibrating business environment because it creates a framework able to handle unpredictability and complexity in a project and makes teams able to create higher value more frequently, ultimatly resulting in higher customer satisfaction.

To form the basis of an Agile approach to projects the Agile Manifesto (p.9-14) was created. It is based on software development but applied across industries. The Agile Manifesto is:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

With this in mind the application of Scrum will be presented.

Application

Scrum is applied as a framework for managing the project life cycle development from idea to finished product. Figure 1 provides an overview of the Scrum Framework consisting of the roles, events and artifacts. Literature on Scrum implementation in software projects incorporates further roles in the framework(p.35-55 and p.16-18) than illustrated in Figure 1, though the figure explains how the Scrum framework can be implemented in any project regardless of type. The figure is based on the Scrum Framework Poster from Home of Scrum. Based on this figure, the framework will be described in the following section, focusing on how to implement Scrum.

Figure 1: The Scrum Framework (own figure based on The Scrum Framework Poster from The Home of Scrum)

How to implement Scrum in your project

Scrum is a simple framework that is hard to apply(p.34). The following section will provide a practical guide in how to implement Scrum in your project by utilising the Scrum framework as described below. The implementation guide is inspired by KnowledgeHut (2019), Sutherland Ph.D, Jeff; Schwaber, Ken(2008) and M. Gannon (2013). As no two projects are identical, the Scrum Framework will have to be adapted to every project to ensure a successful implementation. This overall guide describes all required steps to follow to implement Scrum as an Agile framework. All parts in the Scrum framework are described in further detail below.

1. Identify a Product Owner The Product Owner should be a person able to work with several stakeholders and be able to formulate their wishes and needs into requirements in the Product Backlog, or, in short, act as a customer representative(p.12). Strong personal-, communication- and prioritization skills are needed to successfully do the job of a Product Owner as he/she entirely owns and prioritizes the Product Backlog after business value which is vital for the progress of the project.

2. Build a cross-functional Development Team The Development Team consists of up to nine people with the necessary competences and expertise (e.g. analysts, testers, designers, developers) to fulfil the desired product. They will work closely to provide a quality product. It is preferrable that the team is cross-functional and self-organizing to incentivize ownership of the project. The team member should also be able to change and adapt during the process(p.7).

3. Choose a Scrum Master with the right skills The Product Owner will define why the project is necessary, the Development Team will define what should be done in order to create the desired value and the Scrum Master will define how the work should be done in order to reach the targets. Great Scrum Masters can have varying backgrounds (Project Management, Engineering etc.) but most importantly is that they are not managing the team. They are simply serving the team with whatever they need, to be successful in their work(p.20).

4. Build and Prioritize the Product Backlog After having set the team, the next vital step is for the Product Owner to start building the Product Backlog. The Backlog will be prioritized according to customer and business value written as User Stories. The Product Backlog will be regularily adjusted as the project progresses(p.21).

5. Perform Sprint Planning Based on the Product Backlog, the User Stories ready for work will be planned for the next Sprint and placed on the Sprint Backlog managed by the Scrum Master and the Development Team. As part of the first Sprint Planning, agreements on how to work, commitments and the Product Goal will also be defined. For each Sprint, a Sprint Goal will be agreed upon in the Sprint Planning session.

6. Start working on the Sprint deliverable Start sprinting! Work towards the Sprint Goal and the Definition of Done (see later section for definition). Work according to the commitments made in the Sprint Planning.

7. Have Daily Scrum meetings Every day at the same time during the Sprint, the Scrum Master will facilitate a Daily stand up meeting where the team inspects and adapts to each other to increase transparency and remove impediments(p.24).

8. Perform a Scrum Review at the end of the Sprint At the end of the Sprint, the Scrum team demos the Increment to the rest of the team and relevant stakeholders(p.25). The outcome of this meeting is items (new/adjusted) or requirements to the Product Backlog.

9. Perform a Sprint Retrospective The Retrospective meeting gives the team a chance to reflect about the Sprint and on areas to improve during the next Sprint. Here the team will inspect and adapt to perform better in the next Sprint(p.4+7).

10. Refine and adapt the Product Backlog if needed and start at 5. again The Product Backlog will be prioritized and a new Sprint will start.

To dive deeper into how Scrum is implemented, the Scrum Framework will now be described.

---

The Scrum Framework

The Scrum framework consists of the SCRUM values, the SCRUM team, events and artifacts. The Scrum team roles, events and artifacts are illustrated in figure 1 according to where in the process they adhere. The success of Scrum depends on how well the framework is followed and adapted to the individual project.

The Scrum values

The five Scrum values are: Commitment, Focus, Openness, Respect, and Courage(p.4). The Scrum team is committing to the goals of the project and as they work and learn from the Scrum framework, the values are incorporated in their way of collaborating with each other. The values define important aspects needed for the team to perform well sprint after sprint, which is based on mutual respect and the pillars of Scrum (transparency, inspection and adaption). In this way, the mindset is in place for the team to start working.

The Scrum Team

The full Scrum team consists of the Product Owner (PO), the Scrum master (SM) and the self-organizing Development Team (DT). As a general rule, the team consists of up to 10(p.5 and p.16) highly skilled, professional and self-managing people working in a cross-functional environment. The team will deliver value each sprint and work together towards the product goal (the future state(p.11)). According to the goal and nature of the project, the composition of the team will be settled with people with the required competences.

The Product Owner (PO) The Product Owner has the overall responsibily for communicating the product goals, defining and managing the Product Backlog. The PO decides which items should be in the Product Backlog and how they should be prioritized according to business benefit and value. The Product Backlog needs to be transparent and visual for the rest of the team to understand the progress(p.5-6). It is important for the PO to justify why a Backlog item is important for the team members to buy in and understand the purpose. In this way, the team invests more in the sprint. It is the teams' responsibility to find out how to reach the PO's goals for the product. Furthermore, the PO has the responsibility of communicating with internal and external stakeholders and translate their requirements into project goals if relevant(p.39-42). During the project, as seen in figure 1, the PO is involved in almost the whole project. Firstly, defining, prioritizing and managing the Product Backlog, secondly, communicating to the Scrum team which items that provide highest business value for the coming sprint, thirdly, review the Sprint Increment and discuss the outcome with stakeholders, and last, adapt the Product Backlog according to the Sprint Retrospective.

The Scrum Master (SM) The Scrum Master is responsible for the SCRUM rules are complied with and therefore also the effectiveness of the team. The Scrum Master makes sure that the Development team has understood the Scrum theory and practice(p.6). It is a vital role in the Scrum team, because she helps out whenever there is an obstacle or an impediment in the way of effective working. She is the servant-leader to the Development team(p.6 and p.17) and her job is to keep their day free from disruptive tasks and blockings in order for them to be successful. The SM is also a facilitor of the Scrum events to make sure that the events are value-adding, not wasting valuable time and within the timeframe(p.45-54). When life gets tough, the SM will be the motivator and join with encouraging language to get the morale up. All in all, the SM's most important job is to help out both the PO, the Development Team and the organization by e.g. helping the PO with the management of the Product Backlog, coaching the organization in Scrum adoption(p.7), ensuring an empirical approach and removing impediments to enable them to be successful. In figure 1, the SM is ubiquitous, meaning she is part of the full process. Even though, she cannot be everywhere all the time, she is the person to go to, whenever a problem or a success is encountered.

The Development Team (DT) The Development Team are the ones who develop the product. The DT consists of skilled profesionals assigned according to the task and their competences. They are self-managing as a team, commit to the Sprint and take responsibility for the deliverables. Often there will be roles as quality engineer, technical writer and an architect especially for software development(p.16-18). The DT will create a plan for each Sprint (Sprint Backlog) with the most important and valuable tasks to be completed, then they will define the Definition of Done (see further below), devide the work according to skill and capacity, work on the deliverables while constantly adapting their work towards the Sprint Goal and deliver a increment at the end of the Sprint. During the Sprint Retrospective, the DT will learn by the previous Sprint experiences to improve for the next one. They will hold each other accountable for their work and for their own responsibility towards their own time, skill and capacity(p.5). Before moving in to the first Sprint, intitial agreements needs to be set. This includes team rules, working agreements and responsibilities. A team which are not on the same page from the beginning of a project is doomed to fail, which explains the importance of working agreements and struture. Read more about team structures in McKenna, Dave (2016) p.55-61. This can include agreements of working time and place, team values, a code of conduct and so on. A template such as the Working Agreement Canvas created by ScrumInc. can be utilised. The benefit of creating a working agreement from the beginning is that all team members know what actions should be taken, if trouble occurs, and a unified way of working is agreed upon.

Scrum Events

The Scrum Events are the core of what makes Scrum an excellent agile framework because it creates a collective and understood rhythm for the team. The framework is based on working in iterations (called Sprints). After the PO has defined the scope of the project, the first sprint can begin. All other events work as a part of the Sprint, this will be described in further detail. Having figure 1 in mind during this section will be beneficial.

Sprints The Sprint is the backbone of the Scrum. The Sprint is a 2-4 week(p.7 and p.30-31) period where ideas turn in to value by the DT, to achieve the Sprint Goal. By keeping the Sprints short, focus and engagement will not be lost, risks can be mitigated quickly and the predicability rises. The Sprint is one iteration resulting in a product increment (a minimal viable product or potentially shippable product(p.30-31)). The Sprint consists of all the Scrum events described below. The Sprint starts of with a Sprint Planning event that will define the Sprint Backlog based on the Sprint Goal which is derived from the Product Backlog and the PO's priorities. Once the Sprint Backlog is set, the work can begin. During the sprint, the SM hosts a Daily Scrum meeting for the DT to keep each other informed during the process. This will increase predictability, decrease risk, highten transparency and ultimatively adaptability. When the work complies with the Definition of Done (see below) an increment is born. The product Increment will be demoed to PO and stakeholders in a Sprint Review. Inputs from stakeholders will result in changes to the Product Backlog. The last event in the Sprint is the Sprint Retrospective where the DT has time to evaluate the Sprint's ups and downs and learn from it (empirical work). The learnings will be carried on to the next Sprint. The next Sprint start immediately after the end of a previous Sprint(p.7). The individual events will now be explained in further detail.

Sprint Planning The Sprint Planning is the first event of the Sprint. During the planning, three topics will be adressed: Why having this Sprint? What can be done? How will the work get done?(p.8). During the first point, the PO will explain how value can be increased during the next Sprint, this provides transparency and understanding to the team. The team will hereafter define the Sprint Goal. During the second point, the PO, SM and the DT agree on which user stories should be in the forth-coming Sprint according to the Definition of Ready (see below). The user stories that are ready will be a part of the Sprint and the purpose is for the DT to define work tasks (story points) of the user stories. The PO will act as a customer representative and answer the questions coming from the DT. One user story might be split up to 10 story points which is specific tasks to complete during the Sprint(p.81-87). Lastly, the DT will create a plan on how to get the work done during the Sprint to produce the desired increment. This planning should take max eight hours for a one month Sprint.

Sprint Goal In each Sprint, there is a Sprint Goal. The Sprint Goal is agreed upon by the Scrum team and defines why the exact Sprint is valuable for customers. The goal must be finished before the end of the Sprint Planning session in order for all members to leave the meeting knowing what the purpose with the coming Sprint is(p.11).

Definition of Ready(DoR) The Definition of Ready will be defined by the PO and applies to the user stories. When the PO is working with the Product Backlog, he/she must prioritize the user stories in the Product Backlog according to how close they are to being ready for the team to work with and substantialize. The DoR defines when a user story is ready to be added to a Sprint. DoR should be used in the same way for all user stories but can evolve as the project progresses. It is convenient to follow the INVEST scale when assessing if user stories is well defined, which mean they should be: Independent, Negotiable, Valuable, Estimable, Small and Testable(p.75-77).

Definition of Done (DoD) Along with the Sprint Goal definition, the Definition of Done also needs to be defined during the Sprint Planning event. The DoD is a state of quality the increment needs to meet before it can be deemed done. This ensures transparency and that no task is being pushed ahead(p.12 and p.32-33). If an item does not meet the DoD requirements it will go back to the Product Backlog and be revised further.

Daily Scrum The Daily Scrum (or a Scrum Meeting) is a daily stand-up meeting of a fixed duration of 15 minutes at the same time every day and its intend is to inspect the progress of the team. The meeting will ensure that communication will be promoted and any potential problems or impediments will be solved quickly. This is a chance for the team to make adjustments in the plan to be sure to reach the Sprint Goal(p.9). The event is created for the Development Team and the Scrum Master will facilitate the event. The Product Owner has optional attendance. During the meeting, three questions should be answered: What did I do since the last meeting? Were there any blockages? What will I do before our next meeting?(p.20-21).

Sprint Review The Scrum team demos to the relevant stakeholders what backlog items have been completed during the Sprint according to the DoD. In general, the Sprint Review is the PO's show since he/she has relations to the stakeholders and thereby further builds the relationship with them. The DT gets to showcase the features of the product if relevant. The items are inspected, adaptions towards the Product Goal will be discussed and the Product Backlog will be adjusted. If a test of e.g. a software can be presented to the stakeholders, it is of interest. The session should last at most four hours for a one month sprint(p.9 and p.182-183).

Sprint Retrospective The last event in the Sprint is the Sprint Retrospective. In this event, the Scrum Master hosts a meeting for the Development Team to inspect and adapt to how the Sprint went. The team can raise concerns and problems if any but the meeting should be kept positive and the outcome will be two or three actions to improve during the next Sprint. When the next Sprint Retrospective is up, the actions can be revised. The team will probably talk more freely when the PO is not attending the meeting but if the relationship to the PO is good, then he/she can attend(p.92-94).

Scrum Artifacts

The artifacts of Scrum indicates work or value and will increase transparency in the framework.

Product Backlog The Product Backlog is owned by the PO and it is a list of all the requirements and other related attributes from the customer that needs to be fulfilled to reach the Product Goal. The Product Backlog consists of several items descending in priority and specificity. These items can be epics which are general and logical groupings in the backlog and consists of several user stories. An epic does not fit into one Sprint but may be splitted up and executed across several Sprints(p.28). Another item on the Product Backlog can be a user story, which is some defined work that will create value for the customer(p.78). A User Story can beneficially be written in the following format: "As a [name or role of the end user] I want [simple description of functionality] so that I have [business value]"(p.2). It is the PO's responsibility to decide what is on the Product Backlog, to prioritize the user stories and decide which stories goes in for each Sprint.

Sprint backlog The Sprint Backlog will be created by the DT during the Sprint Planning session. It is a plan for the next Sprint consisting of the Sprint Goal explaining why the Sprint is valuable, a set of items (user stories) from the Product Backlog to define what work should be done and a plan for how to reach the Increment. As a part of breaking down the user stories to story points, an hourly estimate is provided for each task. The Sprint Backlog should be highly visible to be transparent for the team to read. To accommodate structure, a Kanban board can be used as seen in figure 2 below. Here the team members will place sticky notes on the board with tasks and move them as the work progresses from To Do to In Progress to Done or defined according to the project nature. In this way transparency in the distribution of tasks are met. During the Sprint, as the work is inspected in the Daily Scrum meetings, adaptions and adjustments will be necessary for the team as they learn more details(p.11). The progress of a Sprint can be visualised by a Burndown chart(p.85-87) but not replace the importance of empiricism(p.8). As each task is estimated in hours, it is possible for the team to see how much work has been done compared to the calculated amount. An example of a Burndown Chart can be seen in figure 3.

Figure 2: A Kanban board to keep track of work tasks in each Sprint (own figure based on Porter2017). Figure 3: A Burndown Chart to visualize the remaining work in the Sprint (own figure based on McKenna, Dave(p.86))

Increment An Increment is a concrete piece of usable work, working together with all other Increments to create the Product Goal. The Increment should be thoroughly verified and meet the DoD before it is called done. An Increment is done whenever, meaning more Increments can be produces during one Sprint, as long as they follow the DoD(p.11-12).

Pitfalls and their Mitigations in Scrum Implementation

Every organisation that wants to implement Scrum will face their difficulties at some point. Here are some common pitfalls and how to mitigate them to succeed with the Scrum implementation.

1. The Scrum Framework is extensive but does not describe every aspect of what is needed to do. The framework provide a lot of information but not all information or aspects may be relevant for all projects. It is up to the individual and the Scrum Master to pick the right elements and provide other necessary practices from elsewhere to succeed. The framework should not prohibit or discourage any practice, just because does not say so in the framework(p.27-28). To mitigate discouragement, critical thinking and speaking to the experienced Scrum Master would be an idea.

2. Time management and estimation. The team will probably have issues, especially in the biginning, with estimating how much they can do within a Sprint, which will cause frustration and questioning the framework(p.27-28 and p.6). Scrum is a new way of working and will need a cultural change in the organisation to fully succeed (institutionalization(p.89)). To mitigate this, speaking to an experienced Scrum practioner will ignite the needed experience to become better in managing time.

3. Lack of engagement from team members or lack in performance. Getting all team members committed to the task of utilizing the Scrum Framework might impose problems with resistance, lack of understanding and lack of willingness to change(p.27-28). This could be solved by improving understanding and responsibility for the practioners by providing them with training in Scrum.

To obtain an organization that ensures that the relevant processes are considered along with an efficient implementation embracing change, a mix of CMMI and Scrum can be utillized. For further reading see Sutherland Ph.D, Jeff; Schwaber, Ken(2008): The Scrum Papers p. 85-89.

Limitations

SCRUM is extending the current practice of project management but cannot always be applicable. For projects of less complex nature, the Scrum Framework is not the obvious choice due to an extensive framework based on iterations and feedback loops, which may not be nescessary in 'straight-forward' or 'business-as-usual' projects. Jeffrey A. Livermore explains how several factors can impact the implementation success of an agile framework as Scrum.

Training on the methodology: Especially training on the methodology for the project team is highly nescessary for the success of Scrum. if all team members are on the same page and understands the framework, several problems can be mitigated.

Active management support: The more active and involved management is in implementing the framework, the better result.

Access to external resources: Access to knowledge will, obviously, increase the project team's ability to understand the subject to improve throughout the project. As the team is set in the beginning valuable consultant work is excluded.

Other issues stated by Akif, R., H. Majeed (2012) includes a pile up of quality related items due to the high speed in the project execution. Lack of training is also mentioned as an issue. The need for documentation is also stated as an issue, and therefore, Scrum may not be applicable to projects with a high documentation need. Potential scope creep may occur due to an indefinite end-date for the project.

Furthermore, a general issue to implement Scrum in an organisation is the cultural change it entails. Scrum is not just a tool to be used during a project, it is an entirely new way of working and thinking project managment, which of course needs time and effort to implement in an organisation.

Most literature on Scrum implementation and Agile development is based on the software industry and projects. Where Scrum encounters limitations is in the usefullness for physical product development projects where constraints of physicality is met. Constraints of physicality means that there is a physical bound to what is managable to complete in one iteration, e.g. is it impossible to build a suspension brigde in four weeks. As demand and uncertainty also is present in non-software industries, the need for an agile method is great. Even though Scrum may not be directly applicable for physical product development yet, the work and research is moving towards that stage.

Annotated Bibliography

The annotated bibliography desribes in short the most relevant references used in this article. These references are of great use for further reading regarding the subject of Scrum and agile development.

1. Sutherland Ph.D, Jeff; Schwaber, Ken(2020): The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game. Retrieved from https://www.scrumguides.org/ This is the official Scrum guide, written by the two founders of Scrum, Ken Schwaber and Jeff Sutherland. The guide is continously updated as new research becomes relevant and the latest edition from November 2020 is used.

2. The Art of Scrum (2016) How Scrum Masters Bind Dev Teams and Unleash Agility. Dave McKenna, Apress, Berkeley, CA. Retrieved from https://doi-org.proxy.findit.dtu.dk/10.1007/978-1-4842-2277-5 Dave McKenna is an experienced Scrum Master and has written this book with a focus on the Scrum Master's perspective. It gives valuable and practial insigths in to how Scrum actually is applied in real life. This reference is relevant for both new users of Scrum to get a practical understanding of Scrum but also for more experienced individuals who wish to broaden their knowledge.

3. Sutherland Ph.D, Jeff; Schwaber, Ken(2008): The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.814 A book by the co-founders of the Scrum Framework, Jeff Sutherland and Ken Schwaber. This is a book with focus on agile software development and the Scrum framework, both introduction and further deep dive.

4. Bibik I. (2018) Agile Scrum Deep Dive. In: How to Kill the Scrum Monster. Apress, Berkeley, CA. Retrieved from https://doi.org/10.1007/978-1-4842-3691-8_3 Chapter 3 in 'How to Kill the Scrum Monster' another practical guidance in how implement the Scrum framework.

5. Youtube video KnowledgeHut(2019): How to implement Scrum in your team | Scrum Guide | 6 steps to get started with Scrum. Retrieved from https://www.youtube.com/watch?v=J3cMJJGNY4g&ab_channel=KnowledgeHut KnowledgeHut is a global ed-tech company, helping organizations and professionals unlock productive excellence through skills development (from https://www.youtube.com/c/Knowledgehutglobal/about)

6. M. Gannon, "An agile implementation of SCRUM," 2013 IEEE Aerospace Conference, Big Sky, MT, USA, 2013, pp. 1-7, doi: 10.1109/AERO.2013.6497388. URL: https://ieeexplore-ieee-org.proxy.findit.dtu.dk/stamp/stamp.jsp?tp=&arnumber=6497388&isnumber=6496810 Abstract: Is Agile a way to cut corners? To some, the use of an Agile Software Development Methodology has a negative connotation - “Oh, you're just not producing any documentation”. So can a team with no experience in Agile successfully implement and use SCRUM?