CS-C2130 - Software Project 1, Lecture, 4.9.2024-20.11.2024

Contents

0. Introduction
1. Scrum Team
2. Project Effort
3. Product Vision
4. Product Backlog
5. Scrum Events
6. Definition of Done
7. Process  Overview
8. Technical Overview
9. Proposing Changes to the Requirements

0. Introduction

Scrum is a widely used process framework for managing complex product development. Learning to apply Scrum is one of the main educational goals of this course. Therefore, all teams must try using Scrum as defined in the Scrum Guide, but also considering the exceptions mentioned in this Project Manual. If some Scrum requirements fit poorly into the project, the team may propose changes to them as described at the end of this document.

This Project Manual 1) summarizes briefly the requirements set in the Scrum Guide (Schwaber and Sutherland, 2020), and 2) describes the modified/additional requirements set by the course. Read The Scrum Guide (or the more concrete Scrum Primer) in order to understand better why and how to follow the instructions presented below. Note the Changes between 2017 and 2020 Scrum Guides.

See also the following pages, which contain some additional requirements for the course projects: EESs, Project Reviews, Peer testing, Gala.

1. Scrum Team

See Scrum Primer pp. 4-5.

The Scrum Team consists of the Product Owner (PO), Scrum Master and Developers.

The Product Owner is accountable for 1) maximizing the value of the product resulting from the work of the Scrum Team, and for 2) effective Product Backlog management. The PO is a single person from the Client's organization.

The Developers take responsibility of delivering a potentially releasable increment of "Done” product at the end of each Sprint. They are SW Project 1 & 2 course students. 

The Scrum Master ensures that both the developers and PO understand and adhere to Scrum. The Scrum Masters are students from the SW Project 3 course. In this project, the Scrum Master should at least:

• study, plan, teach and ensure the application of Scrum in the Scrum Team
• ensure the adherence to other course requirements described in the Project Manual
• prepare and lead the Scrum events
  
• manage team building (recruitment, team spirit, communication practices)
• oversee that the Developers learn to proceed the project on their own initiative
• initiate discussions on any problems, if the team does not react to them
  
• give tips on methods and tools that have been taught on the SSE major's core courses related to e.g. testing, requirements engineering, and software design
• work also as a developer, if the Scrum Master's responsibilities don't take the whole time budget (especially when taking >5cr course version)
  

2. Project Effort

Each student must allocate 25 * (credits - 1) hours for the project (e.g. 10cr ~ 225h, 5cr ~ 100h). The effort worth 1cr is spent before the project for the lectures, studying Scrum, forming the team, and selecting the topic. Furthermore, Scrum Masters may decrease 15 hours from their project budget, if they participate to the CSM training.

The course requires that the total effort spent per student per each Sprint is updated weekly and visible to the Scrum Team and the Coach. A simple solution is to use a spreadsheet (see an example of a Time Tracking spreadsheet).

3. Product Vision

The product vision is the overarching goal every project stakeholder shares. The input comes mainly from the PO, but it is important that the Developers formulate the Product Vision in order to show that they have understood what the project is about. The course requires that the Scrum Team creates a short product vision (see the template), which

• describes why the product is being built (the business view)
  
• describes the Product Goal, i.e. the desired state of the product in the end of this project (see Scrum Guide)
  
• characterizes the end users
  

4. Product Backlog

See Scrum Primer pp. 5-8.

The Scrum guide requires having a Product Backlog which is an emergent, ordered list of what is needed to improve the product. Typically, not all the items in the Product Backlog will be implemented during the course project. The Product Backlog includes primarily new customer features, but also other types of items (improvement goals, research work, even known defects).

The Product Backlog is never complete, and its earliest development only lays out the initially known and best-understood requirements. Higher ordered items are usually clearer and more detailed than lower ordered ones. The items that are most likely to be selected to the next Sprint are refined so that they can reasonably be "Done" within one Sprint. Refinement adds details such as a description, order, and effort estimate (e.g. in story points). The course requires that the description of those Product Backlog items that represent new software features follows some commonly used user story template (see e.g. Wikipedia-User story).

5. Scrum Events

The different Scrum events are introduced below. In this course, a developer typically spends only 30-40h per Sprint. Therefore, the Scrum events should be short and efficient leaving enough time for the development work. Furthermore, the Sprint Review, Sprint Retro and Sprint Planning events can be combined into a single sprint change event. The Sprint Planning event can be further shortened, if some effort is allocated during the Sprints for refining the Product Backlog (See Scrum Primer pp. 13).

5.1 Sprint

The Scrum Guide requires splitting the project into Sprints. Each Sprint starts with the Sprint Planning event and ends with the Sprint Review and Sprint Retrospective events.

The course requires that the project contains at least 6 Sprints (includes "Sprint 0"). In the beginning of the project, the Scrum Team must plan 1) the start and end dates of the Sprints, and 2) allocation of the budgeted effort per Sprint per student. The course recommends planning equal effort instead of equal duration for all the Sprints, considering e.g. exam weeks.

First Sprint ("Sprint 0")

In this course, the typical Sprint Goal for Sprint 0 is to set up the project so that everything is ready for starting software development work from the first day of the following Sprint. Sprint 0 results must be presented also to the Coach in addition to the normal audience.

At least the following tasks must be completed in Sprint 0:

• team building activities
  
• crafting the Product vision
  
• creating the initial Product Backlog (initially known and best understood requirements)
  
• prototyping, selecting and studying technologies (decisions documented in the Technical overview)
• selecting initial work methods and tools (documented in the Process overview)
• setting up the development environment on developers' computers
• creating the initial Definition of Done
  

Last Sprint

In this course, the last Sprint focuses on finalizing the product for the final delivery to the PO, and on presenting the results and experiences of the project to the course personnel and other stakeholders. 

The last sprint must end before the last project review and contain at least the following tasks:

• acceptance testing by the Client
  
• bug fixing and finalizing (usually no more new features)
  
• handover to the Client (both the system and any necessary knowledge)
• preparing an excellent software demo and a project poster
  
• creating the final report slide-set
  

5.2 Sprint Planning

See Scrum Primer pp. 8-11.

The Scrum Guide requires having a Sprint Planning event which produces the Sprint Backlog for the Sprint. The planning contains three parts:

1. Why? Based on the proposal from the PO the whole Scrum Team defines a Sprint Goal that communicates why the Sprint is valuable to stakeholders.
2. What? Through discussion with the PO, the Developers select items from the Product Backlog to the Sprint. The Developers' knowledge about their past performance, their upcoming capacity, and their Definition of Done, help them decide how many items can be selected to be implemented.
3. How? The Developers plan the work necessary to implement the selected Product Backlog items. This is often done by decomposing Product Backlog items into small work items of one day or less. Small work items help 1) understanding what concretely needs to be done, and 2) tracking the progress of the sprint.

Thus, the Sprint Backlog must contain: 1) the Sprint Goal, 2) the Product Backlog items selected for the Sprint, and 3) the actionable plan for delivering them. The Developers modify the Sprint Backlog throughout the Sprint as they learn more about the work needed.

The course requires that the actionable plan must include an up-to-date list of the necessary work items with a name or description. Furthermore, if the work items are much larger than a day, they must have an effort estimate as hours or points. 

The course requires that the Product Backlog and Sprint Backlogs are online in an adequate tool. Some examples are JIRA, Trello (with suitable Scrum extensions) or a well organized Miro board.

5.3 Daily Scrum

See Scrum Primer pp. 11.

The Daily Scrum is a max. 15-minute event for the Developers to inspect progress toward the Sprint goal and adjust the upcoming work in the Sprint Backlog as necessary.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings. If discussion is required, have one or more follow up meetings after the Daily Scrum with the needed people.

The course requires having the "Daily” Scrum at least once per week. If the team cannot work together regularly, having an online meeting (even asynchronously) is better than having no meeting at all.

5.4 Sprint Review

See Scrum Primer pp. 13-14.

The Scrum Guide requires having a Sprint Review event at the end of each Sprint. The Scrum Team and possibly other stakeholders review the results of the Sprint and possible changes in the environment. They collaborate on what to do next and may adjust the Product Backlog.

5.5 Sprint Retrospective

See Scrum Primer pp. 14.

The Scrum Guide requires having a Sprint Retrospective event at the end of each Sprint. In the retro the Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. The Scrum Team identifies the most helpful changes to improve its effectiveness, and may even add them to the next Sprint Backlog.

5.6 Summary of the Scrum Events

The responsibilities of the different Scrum Team members in each Scrum event are summarized in Table 1. However, the entire Scrum Team is collectively accountable of successful completion of the events. 

6. Definition of Done

See Scrum Primer pp. 8.

The Scrum Guide requires having a Definition of Done (DoD) so that the Scrum Team can have a shared understanding of what it means for a Product Backlog item to be complete. As the Scrum Team matures their DoD will expand to include more stringent criteria for higher quality. If something is not realistic to check for every item separately, it is useful to define DoDs for different levels such as a feature, sprint, and release.

The course requires that the DoD must consider adequately at least:

• unit testing
  
• functional system testing 
  
• usage of a specified coding standard

Furthermore, the course requires that in addition to aiming at functional correctness (=no bugs), the Scrum Team must identify the most relevant quality attributes (at least one, but not too many), and consider them appropriately in DoD. Typical quality attributes include, e.g., usability, security, performance, and compatibility (e.g. targeted operating systems or browsers and their versions, or phone models). “Good usability” or “adequate performance” are vague goals, but quantifying them with some concrete metrics helps to understand and evaluate them better.

See also the information about the Peer testing practice used on this course.

7. Process Overview

The course requires documenting briefly the currently used work practices and tools so that the Scrum Master, Developers, PO, Coach and other course personnel can understand how the team works. Use tables, bullet points, pictures etc. to make it easy to read. The main goal is not to produce a document but to adopt good work practices that can be realistically used. Sprint Retros will certainly lead to changes in the work practices.

The Process overview must contain at least the following content (or links):

1. Project Schedule and Effort

• start and end dates of all Sprints
  
• allocated effort per person per Sprint
  
• dates of other important events such as project reviews
  

2. Scrum Events

• Sprint Planning, "Daily" Scrums, Sprint Review, Sprint Retrospective
  
• Concrete, short description of how the events se are organized (e.g. preparations, participants, content of the event, expected results)

3. Other Main Practices and Tools

• related to project work (backlog management, time tracking, communication, team work session etc.)
  
• related to development work (version control, testing etc.)
  
• Concrete, short descriptions of each practice and tool
  

8. Technical Overview

The useful extent and content of technical documentation depends largely on the project. Generally the documentation should consider two things:

1. Helping the Scrum Team during the project, e.g., in communicating about the design or in dividing responsibilities.
   
2. Meeting the client organization's needs after the project. Therefore, focus on what is complicated or not obvious from the code or code comments.
   

The course sets only minimal requirements for the technical documentation: 

1. Document briefly the most important architectural design decisions. Such design decisions may address, e.g., how the system is divided into its parts, what responsibilities these parts have, what are the interfaces, and what are the used frameworks and technologies.
2. Document one or more relevant views of your architecture design. See, e.g., viewpoints (Rozanski & Woods), C4 model, or arc42.

Otherwise the Scrum Team needs to decide themselves what needs to be documented. The course provides no template for the document.

9. Proposing Changes to the Requirements

Sometimes strict usage of Scrum may not be either educational or productive for a project. For example, the PO may be too busy to take care of all her responsibilities, or the developers fail to arrange regular team work sessions, and must sometimes work as a distributed team. 

However, if in any way possible, the Scrum Team must first try working according to all the requirements mentioned in this Project Manual. Thereafter, they may propose changes to individual requirements, if they fit poorly to their project. A proposal must be sent to the Coach. It must:  

• show that the Scrum Team has truly tried to follow the corresponding requirement(s) and understands their purpose 
  
• describe the problem and the proposed solution
  

Additional Materials

• The Scrum Guide (available also in Finnish)
  
• The Scrum Primer
  
• Scrum Glossary
  
• Slides of the Scrum lectures 
  
• Course Schedule