SCRUM framework

Developed by Sana Ilyas

Scrum is an Agile framework that helps organizations, teams and people to generate value through adaptive solutions for complex problems . The word Scrum originates from rugby to describe a formation of players in a complex game and were first 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 working 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 for software development , Scrum framework encourages iterative and incremental practices to deliver working software in dynamic environments. Unlike traditional Waterfall mythology, 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 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 fixed cost in terms of resources allocated

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

3 pillars of Scrum:

• Transparency is 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 (Work in progress)

• Commitment
• Focus
• Openeness
• Respect
• Courage

Before implementing the Scrum framework, the team must consider the following pre-requisites to ensure a successful implementation and application:

• Scrum require an Agile mindset where flexibility, honesty and communication are at the center. Accepting the Agile manifesto means the lack of a detailed workplans, timelines and scope which can be a big change of mindset and the way a team works.
• The project team must be committet to the values of Scrum
• Scrum does not in particular tell you how to prioritize, estimate or plan. Figuring out how many hours each tasks requires includuing team velocity (number of stories or tasks the team can handle in 1 sprint) is to be determined by the team.

Scrum overview

What does Scrum look like

Scrum is a framework consisting of 6 artifacts, 5 roles and 4 activities.

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 the Sprint is partial product deliverables/features called increments that together form a possible shipable product. Although not all product features must be incorporated at the end of the sprint, however, the increments should be sufficient enough to be released as a functioning product. A sprint can result in 1 or more increments, depending on the size and complexity of the Sprint backlog and team velocity.

• 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 a upcoming or ongoing sprint if the Sprint goal is no longer valueable
• Outcome: Product increment that potentially can 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. 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 mythology, 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 the team decide how to desing, 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 and rececting increments: 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 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. .
• Serving the PO: To make sure that the Product backlog is clear, the SM facilitate the PO with Product Goal definition and management. Subsequently, they 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 .

Recipe for Scrum application

Step 1: Create a Product backlog

1. Plan a workshop where key stakeholders brainstorm user stories. 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 to user stories
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 be able to log into the system using my login so that I can see an overview of my expenses" Note: 1) User stories does 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 Scrum master 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. How do we 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 does not require the PO.
5. PO accepts the plan

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

Output: Sprint backlog, Sprint goal

Step 3: The Sprint and Daily Scrum

Activities that happens 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

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?

Impediments can be solved together with the Scrum master. 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.

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

3.2 Scrum board : To visualize the user stories and their work status, a Scrum board can be applied. 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. However, it s recommended to divide WIP into subsections to keep track of the different phases of development.

An Exapmple of Scrumboad (inspired by Castillo et al., (2016))

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. 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.

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 Scrum framework going forward. For en 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 sprin

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

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

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

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

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

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