Supporting HFOSS using scrum in a capstone course
Authors: Jackson Stoney , Ellis Heidi 
Published: July 2015

This paper reports on a work-in-progress utilizing Scrum to develop a Humanitarian Free and Open Source Software application. CS 390 -- Computer Science Capstone is being offered for the first time in the spring 2015 semester at Western New England University. CS 390 is a prototype for a new capstone course for CS majors with the goal of providing students the opportunity to demonstrate their ability to synthesize and apply knowledge and skills acquired throughout the computer science program while working in teams on a large open source project. MouseTrap, a Humanitarian Free and Open Source Software (HFOSS) application, is being used as the course project with the goal of raising student awareness of ways that computing can improve society [1]. MouseTrap is intended for users with disabilities who cannot use a hardware mouse. MouseTrap uses a web camera to track user head and moves the cursor on screen according to the user's head movement. The impact of student participation in HFOSS in the Computer Science Capstone is being studied. Pre- and post-course surveys are being used to determine student opinions on the humanitarian impact of working on MouseTrap, their technical learning, and their career and future goals. This article describes the course and the current state of the study.

Scrum is an agile approach to software development that emphasizes team collaboration and self-organization, short development sprints, and face-to-face communication among all team members and stakeholders [2]. An outside professor, Dr. Ellis, serves as the product owner and the instructor, Dr. Jackson, plays the role of Scrum Master. The class meets one day a week for 2 hours and 40 minutes over 15 weeks. The course is run as a series of 2-week sprints with sprints ending and beginning in the same class meeting. During these class meetings, all the standard Scrum meetings take place: sprint review, sprint retrospective, sprint planning 1 (sizing and selection), and sprint planning 2 (tasking). The product owner and scrum master meet before this session to groom the backlog. The second class session is in the middle of each sprint. We use this session to hold a scrum-of-scrums, allowing synchronizing between teams; providing technology tutorials; and allowing teams to work together in-person. Outside of class, twice a week, 15-minute "stand-up" meetings are held via Skype for students to identify their progress, set goals to be accomplished before the next meeting, and identify impediments. At the time of writing, we are midway through the second sprint. By the time of the workshop, we will be midway through the fourth sprint.

Student grades are based on their attendance and participation, a portfolio, and peer reviews. 20% of the students' grade is allocated to attendance and participation in this highly interactive class. 60% of the students' grade is based on a portfolio where each portfolio consists of a collection of publically available artifacts that the student authored during the course while working on the project, and a reflection report that references these artifacts and how they have achieved the course's objectives.

Students collect these artifacts over the course of the semester, one per week and students receive regular feedback on their artifacts. Students are required to turn in an early draft of their reflection report, so that the instructor can give more feedback; students earn credit for this too. Last, the final reflection report itself is graded. The last 20% of the students' grade comes from peer reviews. However, we have what we believe is a somewhat unique approach to peer reviews. Every two weeks, at the end of each sprint, students complete a peer evaluation for each of their teammates. These are a 5-point Likert scale with values "very dissatisfied", "dissatisfied", "neutral", "satisfied", and "very satisfied". Using this scale students evaluate their teammates' performance in the following areas:

• Meetings

• Communication

• Cooperation

• Dependability

A constructive and supportive process is used for this peer review. If a student receives an average of less than "neutral" for any area, then the team and the instructor sit down and draw up an improvement plan that provides the student with suggestions and support for improving that score. If the scores don't improve in future reviews, then a new improvement plans is created. However, the student is charged a 15% penalty in the peer evaluation category for the second and third improvement plan. If a fourth improvement plan is required, the student receives a 0% in this category and is removed from the team, and must continue the project on his or her own. This improvement-plan approach places obligations on both the individual needing improvement and the rest of the team, reinforcing the idea that it's everyone's responsibility to help the team member improve.

One interesting aspect to the grading approach used in this course is that students are not graded based on the correctness of their artifacts, but instead on their active participation in the project. This emphasis is important for the use of Scrum and to help ensure the instructor remains an effective Scrum Master. Ideally the Scrum Master is a coach of sorts with very little power. His or her job is to help the team and the product owner use scrum effectively. Students (or anyone really) will make mistakes using scrum. But part of the essence of scrum, or any agile process, is that teams learn and improve as they go along. By not attaching a grade to this improvement, it allows teams to more freely and honestly evaluate themselves and decide how to improve. The alternative is that the team simply does whatever the instructor tells them to so that they can get the grade they want. And ultimately, the students grade would reflect how well students followed the instructor's instructions rather than how well the teams cooperate, adapt, and perform.

MouseTrap and HFOSS in general has been used successfully in classes at Western New England University. This work-in-progress explores the use of Scrum, an agile development approach that emphasizes individuals and interactions of processes and tools, is a development approach that can support student participation in HFOSS. As part of this effort, students were surveyed at the beginning of the course for their opinions on three aspects: 1) the humanitarian impact of the project on their learning, 2) technical learning, and 3) career and future goals. Students will again be surveyed at the end of the course to determine the impact of MouseTrap on their understanding of computing for social good. Scrum's emphasis on collaboration, cooperation and dependability combined with MouseTrap's goal of aiding users with disabilities create an ideal vehicle for conveying computing's capabilities for achieving social good. We are hopeful that student surveys will support this view.