CS-C2130 - Software Project 1, Lecture, 15.9.2021-9.12.2021

Scrum is a widely used process framework for managing complex product development. It is defined in The Scrum Guide. 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 in the end of this document.

This Project Manual 1) summarizes only briefly the requirements set in the Scrum Guide (2017 version), and 2) describes the modified/additional requirements set by the course. You must read The Scrum Guide (or the more concrete Scrum Primer) in order to understand why and how to follow the instructions presented below. See also the Changes between 2017 and 2020 Scrum Guides.

Contents

See Scrum Primer pp. 4-5.

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

PO is responsible of managing the Product Backlog so that the value of the product and the work of the Development Team is maximized. PO may delegate some work to the development team, but remains accountable. PO is a single person from the Client's organization. 

Development Team self organizes and takes responsibility of delivering a potentially releasable increment of "Done” product at the end of each Sprint. It consist of the SW Project 1 & 2 course students. 

Scrum Master ensures that both the PO and the Development Team understand and adhere to Scrum and the requirements set by the course. 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
• prepare and lead the Scrum events
  
• manage team building (recruitment, team spirit, communication practices)
• oversee that the Development Team learns to proceed the project on their own initiative
• initiate discussions on any problems, if the team does not react to them
  
• be able to give tips on methods and tools for at least some of the following: architecture, testing, user requirements, teamwork etc.
• work also as a development team member, if the Scrum Master's responsibilities don't take her whole time budget (especially when taking >5cr course version)
  

2. Project Effort and Time Tracking

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.

The course requires that the total effort spent per student per each Sprint is available to the Coach and updated at least weekly. A recommended way for time tracking is to use a backlog management tool that supports it, but a simple alternative 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 PO, but it is important that the Development Team formulates 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, which

• explains why the product is being build (the business view)
  
• lists the main goals for the product
  
• characterizes the end users
  

4. Product Backlog

See Scrum Primer pp. 5-8.

The Product Backlog is an ordered list of everything that might be needed in the product. Typically, not all the items 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 likely to be chosen to the next Sprint are refined so that any one item can reasonably be "Done" within one Sprint.

The Scrum Team must have a Product Backlog, whose items have 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 SW features follows some published user story template (see e.g. Wikipedia-User story).

5. Sprints

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

The course requires that the project contains at least 6 Sprints. 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 to the Coach and the PO. 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)
• 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 (no more new features)
  
• handover to the Client (both the system and any necessary knowledge)
• preparing an excellent software demo for the last project review
  
• creating the final report slide-set
  

6. Sprint Planning

See Scrum Primer pp. 8-11.

The Scrum Guide requires having a Sprint Planning event where the Scrum Team crafts the Sprint Goal and the Sprint Backlog. The event contains two parts: What and How.

1. What: PO and Development Team decide which Product Backlog items can and will be implemented and what is the objective (Sprint Goal) that will be met through implementing them. The Development Team tells the PO how many items can be selected from the Product Backlog to the Sprint. The Sprint Goal provides guidance on why the increment is built and gives some flexibility regarding the functionality implemented within the Sprint. 
   
2. How: Development Team usually starts by designing the system, and plans into the Sprint Backlog the work needed to develop the selected Product Backlog Items. In a student project it is also crucial to agree when and where the work will be done, e.g. by scheduling all the weekly team work sessions. 
   

7. Sprint Backlog

See Scrum Primer pp. 9-10.

The Scrum Guide requires having a Sprint Backlog, which 1) makes visible all of the work identified so far as necessary to meet the Sprint Goal, and 2) includes at least one high priority process improvement identified in the previous Retrospective. The Development Team modifies the Sprint Backlog throughout the Sprint as they learn more about the work needed.

The Sprint Backlog items must have 1) a name or description and 2) the estimated effort as hours or story points. At least the first Sprint Backlog items must be small enough that the team is able to complete some items in every work session. Completing tasks allows tracking the progress of the sprint. 

The course requires that the Product Backlog and Sprint Backlogs are online in a backlog management tool. The minimum requirements for an adequate tool are:

• intended for managing backlogs (i.e. not just an Excel worksheet) e.g. JIRA Agile, Trello (with suitable Scrum extensions), Version One, or some other similar tool
• supports the required backlog item attributes and the concept of Sprints
  
• a well organized Miro board is also an accepted tool

8. Sprint Review

See Scrum Primer pp. 13-14.

The Scrum Guide requires having a Sprint Review at the end of each Sprint. The developed software increment is inspected with the PO, and the Product Backlog is revised for the next Sprint and overall, if needed.

9. Sprint Retrospective

See Scrum Primer pp. 14.

The Scrum Guide requires having a Sprint Retrospective in the end of each Sprint. In the retro the Scrum Team identifies improvements to the way they work. Furthermore, in each retro improvements to the Definition of Done are planned to increase product quality. Document the results of the retros in order to be able to discuss them in the next retro and project review. 

10. Sprint Change

In this course, a student spends only 30-40h per Sprint. Therefore, the Scrum events should be short leaving enough time for the development work. The required effort can be decreased by combining Sprint Review, Sprint Retro and Sprint Planning events into a single Sprint Change event. The Sprint Planning part can be further shortened, if some effort is allocated during the Sprints for refining the Product Backlog (See Scrum Primer pp. 13).

11. Daily Scrum

See Scrum Primer pp. 11.

The Daily Scrum is a max. 15-minute time-boxed event for the Development Team to synchronize activities, create a plan up to the next Daily Scrum, and report on obstacles. It improves communication, eliminates other meetings and potentially disturbing non-urgent communication, and identifies impediments to development. 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.

12. Definition of Done and Software Quality 

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 or an increment to be complete.  As the Scrum Team matures their DoD will expand to include more stringent criteria for higher quality. Sometimes 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

The course requires also 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 Product Vision, DoD and/or Technical Overview. Typical quality attributes include usability, security, performance, and compatibility (e.g. targeted operating systems or browsers and their versions, or phone models). “Good usability” or “adequate performance” are still rather vague goals, but quantifying them with some concrete metrics helps to understand them better and evaluate their status.

In this course, each team gets a peer team. The peer team must test the system for at least 8 man hours during the latter half of the project using Session-based testing. The peer team must be given at least one Test Session Charter and other necessary materials such as test data and defect reporting guidelines. The peer team must fill the exploration log in the charter.

13. Project Review

The course arranges three project reviews, where the student team presents the project status and results (software demo and other results) to the course personnel, PO, and possibly other stakeholders. Ending one of the Sprints close to a project review simplifies reporting. The absence of some students is accepted, if the participants can answer all project related general questions. After the review, the Coach and PO will evaluate the team according to the Evaluation principles. Section 16 lists the materials which need to be delivered to the participants before the project review.

Create a Progress/Final report slide set and present it in the project review. It must contain at least:

• summary of the results of the Sprints: Sprint Goals, Product Backlog items, and other results
  
• main findings from the Sprint Retros
• a script for and some screenshots of the software demo shown in the review
• evaluation of software quality (peer team's feedback in Final report only)
• spent and remaining effort per person per Sprint 
• realized project scope vs. original/updated product vision (in Final report only)
• complicating and simplifying factors compared to other projects on this course (in Final report only)
• overall evaluation of the used work practices and tools (in Final report only)

Project review agenda:

• Presentation (35 minutes), Students
  
• Questions and feedback (10 minutes), PO & Course personnel & Students
  
• Private discussion on evaluation (10 minutes), PO & Course personnel
  
• Points and further feedback from PO (min. 5 minutes), PO & Students

14. Process Overview

The course requires documenting briefly the currently used work practices and tools so that the Scrum Master, the Development Team, PO, Coach and other course personnel can understand how the team works. A picture is worth a thousand words. 

Note that producing a document is not the main purpose of this activity. The most important thing is 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
  
• other main events such as project reviews
  

2. Description of the recurring events of the Sprints (how and when)

• Sprint Planning, Daily Scrums, team work sessions, Sprint Review, Sprint Retrospective
  

3. Description of other main practices and tools

• related to project work (backlogs, time tracking, communication etc.)
  
• related to development work (version control, testing etc.)
  

15. 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'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: 

Otherwise the Scrum Team needs to decide themselves what needs to be documented.

16. Delivering the Required Artifacts

The course requires that 24 hours before each project review:

• all the required artifacts must be up-to-date
  
• all files must be linked to a web page both separately and as a single zip package
  
• the link of the web page must be sent to the teacher (cs-c2130#aalto.fi), Coach, and PO
  

Do not include any confidential material to the web page, because the link will be published in MyCourses.

If an artifact cannot be linked to the web page (e.g. the backlogs are in some tool, it contains confidential information etc.), mention the reason, and provide instructions to the Coach for accessing it.

The required artifacts are:

• Product vision (see Template)
  
• Product Backlog
  
• Sprint Goals of the current and completed Sprints
• Sprint Backlog of the current Sprint
  
• Definition of Done
  
• Test session charter(s) for peer testing (when needed) (see Template)
  
• Allocated and spent effort per person per Sprint
  
• Process overview (see Template)
  
• Technical overview
  
• Progress report / Final report slides (see Template)

17. Proposing Changes to the Scrum 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 Development Team fails 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 Scrum related requirements mentioned in this Project Manual. Thereafter, they may propose changes to the 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
  

18. Additional Materials

• The Scrum Guide (English and Finnish versions)
  
• The Scrum Primer
  
• Scrum Glossary
  
• Slides of the Scrum lectures 
  
• Course Schedule