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 <refname=Manifesto> http://agilemanifesto.org/ </ref> , 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

• Commitment
• Focus
• Openeness
• Respect
• Courage

Before implementing the Scrum framework, hte team must consider the following pre-requisites to ensure an 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.

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 (clafifying and adding important details to user stories that are nessacary for the developers before they can initiate the development (DoR?) 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.

• 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: 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 Scrum Master 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 Scrum master helps coaching the team in how to work as a cross functional and self-organizing team. Additionally, the Scrum master 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 betweenUser 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 or 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

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 part of the company 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 PO presence is not mandatory every time (because they ususally are from another part of the company fx sales, marketing and thus are busy with other tasks) but should prioritize this meetings as well.

Limitations and challenges

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

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

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