SCRUM framework

Developed by Sana Ilyas, DTU (s192815)

Scrum is an Agile framework that "helps people, teams and organizations generate value through adaptive solutions for complex problems" . The word Scrum originates from rugby to describe a formation of players in a complex game. It was later introduced in the context of product development by Hirotaka Takeuchi and Ikujiro Nonaka in 1986 to increase speed and flexibility by implementing a cross functional team that worked in overlapping phases .

Taking inspiration from this formation, Scrum framework is founded on empiricism, proclaiming that knowledge is derived from experience and decision making based on the observed, and Lean thinking which is designed to reduce waste and focus on the essential . Together with the Agile manifesto , Scrum framework encourages iterative and incremental practices to deliver working software in dynamic environments. Unlike traditional Waterfall mythodology, Scrum encourages not to have a defined scope but iteratively decide scope as the project progresses, and to actively work in cross-functional teams while regularly integrating end-users and/or stakeholders in order to constantly validate and prioritize outputs of the processes. Comparing the two methodologies using the Iron triangle, Waterfall have a fixed scope and quality to be delivered while Scrum have a fixed time for when the project should finish along with a fixed cost in terms of resources allocated

Project management tool: Scrum framework is a project management tool and can be viewed as a project life cycle, which is defined as follows in the PMBOK guide: "A project life cycle is the series of phases that a project passes through from its start to its completion. It provides the basic framework for managing the project. This basic framework applies regardless of the specific work involved. The phases may be sequential, iterative, or overlapping.". Scrum is an incremental project management mythodology where input, output and techniques are constantly evaluated and validated throughout the process using the same framework (tool).

Before implementing the Scrum framework, the team must consider whether the following pre-requisites is suitable for their team:

• Scrum require an Agile mindset where flexibility, honesty and communication are at the center. Accepting the Agile manifesto means the lack of detailed workplans, rapid and frequent changes in scope and procedures which can be a big change of mindset and the way a team works.
• The project team must agree upon commitment to Scrum pillars and values (see section below).

Scrum overview

In order to understand and implement Scrum, the team must understand the 3 pillars and 5 values that serves as a roadmap for Scrum:

3 pillars of Scrum:

• Transparencyis an important pillar of the Scrum setup where the outcome and process are visible and clear to stakeholders involved in the project in order for them deliver what is agreed and to give feedback and approve the outcome.
• Inspection is done frequently to avoid undesirable variances in the process and deliverable thus meeting the fixed release date.
• Adaption refers to the ability to adjust to change in processes, scope or any relevant change discovered during inspection. By adjusting to change as soon as possible, the team minimize further deviation going forward .

5 Values of Scrum

• Commitment - Commitment to Scrum principles, common goals and team
• Focus - Focus on what is required to accomplish the goals and improving the setup to increase effectivity and efficiency
• Openeness - Being open and comfortable in the team and open to change
• Respect - Respect for each other and the goals within a sprint
• Courage - Courage to explore new solutions, making mistakes and challenging the status quo

Scrum Framework

Figure 1: Scrum Sprint (inspired by Troels et al., (2019)

Sprint: In a Scrum setup, the project is divided into short iterative cycles called sprints that can vary in duration from weeks to months. Here, the focus lies on development of features in the Sprint Backlog to reach the Sprint goal. The output of a Sprint is partial product deliverable(s)/feature(s) called increment(s) that together form a possible shipable product. Although not all product features must be incorporated at the end of a sprint, the increments should be sufficient enough to be released as a functioning product.

Note: A sprint can result in 1 or more increments, depending on the size and complexity of the Sprint backlog and team velocity (number of stories or tasks the team can handle in 1 sprint).

• Length: typically 1 week - 1 month (2 weeks recommended). Sprints lasting more than 1 month makes it difficult to make nimble adjustments and deploy working software
• Owner: Product owner - The Product owner have the authority to cancel an upcoming or ongoing sprint if the Sprint goal is no longer valueable
• Outcome: Product increment that can potentially be relased

Product backlog and Sprint backlog: All project requirements are gathered in the Product backlog in the form of user stories which is to be defined, prioritized and developed during the project. For each sprint, selected features/user stories are transferred to the Sprint backlog by the Scrum team and developed during the current sprint. Each user story is further sub-divided into smaller and more detailed items called tasks. To keep track of user stories and the progress of tasks, a Scrum board is used. It visualizes the user stories and the tasks for the current sprint and their development from Backlog to Work in progress (WIP) to done (figure 2). Through self management, the team assign tasks to each member and how this task is solved most efficiently. The responsibility for reducing the the sprint backlog relies on the entire team. In scrum mythodology, this is refereed to as "owning" the sprint backlog .

• Size: Depends on the project
• Owner: PO owns Product backlog and Development team owns Sprint backlog
• Outcome: Product Backlog containing all user stories to be developed in the entire project (with subject to change) and Sprint backlog containing user stories for the upcoming sprint

Scrum Team and roles

The Scrum team is a (small) cross-functional team consisting of necessary resources - typically 10 or fewer people since smaller teams has proven to be more productive and have better communication. Unlike many traditional teams, no hierarchy exist in the Scrum Team and they are self-managing meaning, that the team decide how to design, build, test and deliver the user stories

Following roles and associated responsibilities are assigned to members:

Product Owner (PO): The product owner represents the voice of the customer. He/she plays a big role in maximizing value throughout the project and therefore "owns" the Product Backlog. PO responsibilities can be summarized as follows: :

• Owns Product backlog: By taking ownership of the Product backlog, the PO is responsible for translating customer needs and ideas into features also called user stories that is put into the backlog. To do so, the PO needs to 1) express backlog items clearly to ensure that the development team understand what needs to be done 2) Get a user story ready for development together with the development team (clarifying and adding important details to user stories that are nessacary for the developers before they can initiate the development) 3) prioritize user stories to meet the overall objective of the project including Product Goal.
• Communication: The PO should be able to communicate with stakeholders outside the team and work closely with the team to ensure alignment between what is expected and developed.
• Accepting or rejecting output: When an increment or user story is developed, it is the PO's responsibillity to either reject or accept it based on acceptence criterias. Acceptence criterias for each user story are often formed in collaboration with the developers and describes the functional requirements related to the story that must be fulfilled before it becomes a shippable product.

Development team: The development team usually consist of 5-9 people where each member is referred to as a developer. Their collective responsibility is to work on user stories in the Sprint backlog hence deliver value to the customer. The composition of the developers reflects resources required to complete the tasks, thus it can be different professions such as designers, engineers, testers, analysts etc. The development team responsibilities can be summarized as follows:

• Owns the Sprint Backlog: The development team is self-organized and accountable for creating an execution plan for user stories in the Sprint backlog and adapting their plan if necessary in order to reach Sprint goal while bringing value and quality in their tasks.
• Defining the "Definition of done" (DoD): The Definition of Done can be viewed as a formal agreement between the developers and PO that states "what requirements, in addition to the user story's acceptance criteria, you need to fulfill to be done with the story". In other words, it describes the requirements for when an user story in the backlog is completed and ready to be delivered to the customer
• Work cross-functional: It is encouraged that developers do not claim an area of expertise and stick to that. Ideally, every developer should be able to perform different tasks thus being involved in every aspect of the development process. This will prevent bottlenecks and hierachies in the team

Scrum Master (SM): The Scrum Master acts like a facilitator of the Scrum setup including the PO and the Development team. They are often referred to as "servant leader" of the team meaning that they lead by serving the team and being supportive, thus focusing on leadership instead of management. This entails keeping track of timelines, deadlines and keeping the team motivated without micro-management. The Scrum master responsibilities can be summarized as follows:

• Serving the Scrum framework: Promoting, establishing and maintaining the agile scrum best practices and rules within the team thus ensuring that the framework is implemented and used effectively. Practically, this is done by moderating Scrum events eg. Sprint planning, daily scrum etc. and being available to any kind os support needed by the Scrum Team .
• Serving the PO: To make sure that the Product backlog is clear, the SM facilitate the PO with Product Goal definition and management and subsequently help the Scrum Team understand the items within the backlog. If needed, the Scrum Master can facilitate stakeholder collaboration.
• Serving the Development team: The SM helps coaching the team in how to work as a cross functional and self-organizing team. Additionally, the SM facilitate in value creation and efficiency of the team by removing obstacles in their way and ensuring productive Scrum events .

Scrum application for Software development

Step 1: Create a Product backlog

The first step is to create a Product Backlog with relevant stakeholders. This can be done in different ways, 1 way could be as follows:

1. Plan a workshop where key stakeholders brainstorm ideas. Example of key stakeholders could be: end-users, experienced developers, business analysts, customer etc. Here you focus on the bigger picture and do not go into details.
2. Brainstorming results are then converted into user stories (see example below)
3. User stories are prioritized, typically by the PO. Prioritization can be done based on associated risks to each story and/or the business needs related to the project.

Link between User stories and Acceptence criteria

User story 1: As a "type of user", I want "a functionality", so I may have "a business value

Example: As a user, I want to log into the system using my login so that I can see an overview of my expenses.

Note: 1) User stories do not contain details about functions and implementation 2) You can add user stories throughout the project and adjust stories if needed.

Acceptence criteria: Before "User story" can be marked as done, "scenarios or test" must be validated.

Example: Before "User story 1" can be marked as 'done', username and code bar along with a 'forgotten password' botton must be validated.

Note: there can be more than 1 acceptence criteria for 1 user story.

Step 2: Sprint planning

Sprint planning is the first activity and typically lasts 4 hours (for a 30-day sprint) requiring the presence of the whole Scrum team. Here, you address/decide the following:

1. Changes to Product backlog since last Sprint
2. Sprint goal for the upcoming Sprint.
3. User stories to work on during the Sprint. PO and developers collaborate facilitated by SM to select user stories from the Product backlog into the Sprint backlog (with team velocity in mind) along with Acceptence criterias for each story.
4. Decide how the team intend to work on the user stories. Developers further breakdown user stories into tasks and plan how to complete these tasks so they meet the Definition of Done. This step do not require PO collaboration.
5. PO accepts the plan.

Input: Product backlog, team velocity, current product status and constraints

Output: Updated Product backlog, Sprint backlog and Sprint goal

Step 3: The Sprint and Daily Scrum

Activities taking place during a typical Sprint:

• User stories in the Sprint backlog are developed and marked as "done" based on the Definition of done
• Product Backlog refinement: PO and the development team constantly refine and update Product backlog.
• Changes in workflows and cross-functional collaboration to reach Sprint goal.

3.1 Daily Scrum meetings: Daily Scrum meetings are - as the name indicate - held every day for 15 min at the same time and place, typically in the beginning of the day to reduce complexity . The purpose of this meeting is to give a quick status of the progress toward the Sprint goal and provide visibility and alingment between the members and the sprint goal. Every member answer the following questions:

1. What did you do yesterday?
2. What are you doing today?
3. Do you have any roadblocks preventing you from accomplishing what you need to do?

Figure 2: Scrum Board(inspired by Castillo et al., (2016))

Impediments can be solved together with the SM. If needed, an action plan is defined and the issue is escalated within the organization to seek help outside the team.

Note: PO is not obligated to participate in every Daily Scrum. A PO typically belongs to another department eg. Sales, Marketing etc. and are therefore busy with other tasks besides being a PO for the team. However, they should prioritize this meeting to the best of their abillity.

3.2 Scrum board : To visualize the user stories and their work status, a Scrum board can be applied (figure 2). This creates transparency and helps the team to keep track of each task. A Scrum board can be customized to the teams need but typically contain the columns Backlog, Work in Progress (WIP) and Done. It is recommended to divide WIP into subsections to keep track of the different phases of development. The Backlog section contains all tasks related to the user story. As the tasks is assigned to a developer, it is transferred to WIP. When the developer has completed the task by fulfilling criterias in DoD, including Acceptence criterias, the task is evaluated by the PO and put into the section "Done".

Daily Scrum Output: Plan for the day, any obstacles have been adressed

Step 4: Sprint Review

At the end of each Sprint, there is a Sprint review that typically lasts 3 hours (for a 1 month sprint) where the Sprint increments are reviewed. Here, you do the following :

1. Development team presents and/or demonstrate their work to the PO and other relevant stakeholders.
2. Based on the results presented by the development team, the PO discuss and decide which user stories from the Sprint backlog are "done" according to the Acceptance criteria
3. PO and stakeholders give valueable feedback which are discussed with the development team. This is a crucial step since the PO and stakeholders are able to see the prototype and therefore give better feedback of what features they would like to keep and remove for further development.
4. Items from current Sprint backlog that are market as "done" becomes a part of the Increment while items that needs further improvement/development (either by developers or PO), are put back into the Product backlog for next Sprint or refinement.

Output: Learnings from previous sprint that need to be adressed in the coming sprint

Step 5: Sprint Retrospective

Here, the Scrum team reflect upon the completed Sprint in order to increase quality and effectiveness of the team and Scrum framework going forward. For 1 month sprint, this meeting is typically set to maximum 3 hours. Some guiding questions could be

1. What went well during the sprint?
2. What problems did the team encounter and how were they dealt with?
3. What could be improved during the next sprint? including optimization of interactions, processes and tools

Output:1-3 action items to focus on in the coming sprint

Limitations and challenges

Agile practices is becoming more and more popular and it is expected to grow in the future . The reasons for adopting Agile were investigated in a survey conducted by Viosion One in 2020. Here, the top reasons were: "Accelerate Software Delivery" (71%), "Enhance ability to manage changing priorities" (63%), "Increase productivity" (51%), and "Improve business/IT alignment" (47%). Likewise, the benefits of adopting agile were investigated among the respondants, giving the top benefits: "Ability to manage changing priorities" (70%), "Project visibility" (65%), "Business/IT alignment" (65%) and "Delivery speed/Time to market" (60%).

However, here are some limitations and challenges related to the framework:

• Having a core team: In order for the Scrum framework to work, it must be implemented in a core team with limited to no change in roles and quantity. This is due to the collaborative nature of the framework along with the importance of alignment, minimal documentation and cross-functionality of the team.
• Agile culture: The Scrum Framework will not bring the intended benefit if the team do not subscribe to the Agile meninifesto and its 12 principles
• Scrum is not intended for multipurpose projects (projects with severel product development outcomes) which requires many different people/resources to be involved. Instead, managers can implements elemets of Scrum eg. implementing a Kanban board or consider other more suitable tools such as SAFe (Scaled Agile framework) or PRINCE2.
• Having fixed cost, time and demands (including scope) deprive agile development, The developers are (often) solving an unique problem and therefore need a significant degree of freedom to solve it. Otherwise, consider PRINCE2.
• Scrum do not in particular tell you how to prioritize, estimate or plan. Eg. figuring out how many hours each tasks requires includuing team velocity is to be determined by the team.

Bibliography

Troels Jakobsen, "Scrum Done Right - Learn Agile Software Development". Lean Agile Ltd, 1st edition (2019)

This guide provide an excellent description and overview of all the artifacts, roles and activities in Scrum and were especially developed for Scrum Masters as reference work.

Hanslo R., Vahed A., Mnkandla E. (2020) Quantitative Analysis of the Scrum Framework. In: Przybyłek A., Morales-Trujillo M. (eds) Advances in Agile and User-Centred Software Engineering. LASD 2019, MIDI 2019. Lecture Notes in Business Information Processing, vol 376. Springer

This study performs a quantitative analysis of the Scrum Framework using The Spearman collerelation analysis in South African organizations. Of the 14 factors studied, the 3 factors: Sprint Management, Complexity and Relative advantage have shown to have a statistically significant relation with Scrum adoption. This study can be used to gain more knowledge about factors that affect Scrum adoption.

Hron, M., and Obwegeser N., (2018) Scrum in practice: an overview of Scrum adaptions. 51st Hawaii International Conference on System Sciences (HICSS 2018), Curran Associates, Inc., p. 5445-5454.

This study provide an overview of the proposed adaptions and their implications by augmenting or combining the Agile software development practices with other tools and methods. However, this study only covers 31 studies after a filtering process.

References

Schwaber K. and Sutherland J, (2020) The Scrum Guide - The Definitive Guide to Scrum: The rules of the Game. Creative Commons. https://www.scrumguides.org/index.html.

Takeuchi, H., Nonaka, (1986) The new new product development game. Harvard Bus. Rev. 64, 137–146

Agile Manifesto for Software development: http://agilemanifesto.org/

Castillo F. (2016) Agile-Scrum Project Management. In: Managing Information Technology. Springer, Cham. https://doi.org/10.1007/978-3-319-38891-5_8

Project Management Institute, Inc., "Guide to the Project Management Body of Knowledge". Project Management Institute, Inc (PMI), 6. edition (2017)

Troels Jakobsen, "Scrum Done Right - Learn Agile Software Development". Lean Agile Ltd, 1st edition (2019)

Rossberg J. (2019) Introduction to Scrum and Agile Concepts. In: Agile Project Management with Azure DevOps. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-4483-8_3

Weinreich R., Neumann N., Riedel R., Müller E. (2015) Scrum as Method for Agile Project Management Outside of the Product Development Area. In: Umeda S., Nakano M., Mizuyama H., Hibino N., Kiritsis D., von Cieminski G. (eds) Advances in Production Management Systems: Innovative Production Management Towards Sustainable Growth. APMS 2015. IFIP Advances in Information and Communication Technology, vol 459. Springer, Cham. https://doi.org/10.1007/978-3-319-22756-6_69

Hanslo R., Vahed A., Mnkandla E. (2020) Quantitative Analysis of the Scrum Framework. In: Przybyłek A., Morales-Trujillo M. (eds) Advances in Agile and User-Centred Software Engineering. LASD 2019, MIDI 2019. Lecture Notes in Business Information Processing, vol 376. Springer, Cham. https://doi.org/10.1007/978-3-030-37534-8_5

Bianco C. (2011) Agile and SPICE Capability Levels. In: O’Connor R.V., Rout T., McCaffery F., Dorling A. (eds) Software Process Improvement and Capability Determination. SPICE 2011. Communications in Computer and Information Science, vol 155. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-21233-8_16

Vision One,"14th annual State of Agile Report", https://stateofagile.com/?_ga=2.1847793.1975269652.1614501418-1195485270.1614501418#ufh-i-615706098-14th-annual-state-of-agile-report/7027494 (2020)

Lárusdóttir M., Cajander Å., Erlingsdottir G., Lind T., Gulliksen J. (2016) Challenges from Integrating Usability Activities in Scrum: Why Is Scrum so Fashionable?. In: Cockton G., Lárusdóttir M., Gregory P., Cajander Å. (eds) Integrating User-Centred Design in Agile Development. Human–Computer Interaction Series. Springer, Cham. https://doi.org/10.1007/978-3-319-32165-3_10