SPSG Structure Guide #
Overview #
SPSG project structure is grounded in agile practices by focusing on short iterations, customer involvement, and providing enough flexibility to address changing requirements and other challenges. Each project consists of four phases:
Inception,
Elaboration,
Development, and
Transition.
These four project phases are illustrated below, along with the corresponding project activities and deliverables.
Phase durations reflect the scope of the underlying course, as shown below. Here, SE refers to a typical Software Engineering course that combines the theoretical foundation of a software engineering course with a semester-long course project. Here we provide a sample schedule for a typical SE course with the coverage of the material aligned to facilitate the students having the background in time for each of the assignments and deliverables. SP refers to Senior Project (or Senior Design/Capstone) course whose content focuses primarily on the project, along with assigned readings and discussions emphasizing professional and ethical issues. A typical SPSG project lasts two or more semesters. Each course typically includes teams working on a variety of projects for different partners. After the first semester, students who worked on a given project in the SE course, continue into the SP course. In those programs where there is only one course that can host such a project (SE), the project can continue in the next offering of the same course with new team(s). This is discussed in detail in the Instructor Perspective document. Depending on the project and on the curriculum structure, the same students may or may not still be actively working on the same SE project, however a key role is these students remain accessible to answer questions and support the new SE teams in their onboarding process. In this capacity, they engage with new SE student teams, facilitating project continuity and transferring knowledge.
Project Phases and Continuity #
The Inception phase occurs before the semester starts and involves the instructor working with the project partner to determine project feasibility, student skill alignment, scope, duration, and expected outcomes. This results in a standardized project proposal document received by one or more student teams.
During Elaboration, students form teams and work closely with the project partner to understand and formulate project requirements. Alternatively, teams could also be formed by the instructor. For new projects, teams go through several iterations of project partner interviews to form outline requirements, which then are translated into user stories forming the initial product backlog. For continuing projects, remaining user stories are reviewed and adjusted taking into account any new user stories reflecting the next set of requirements. Teams work closely with the project partner to verify that the user stories correctly reflect the desired functionality, while the project partner sets user story priorities.
The Development phase is structured using the agile methodology. Each two-week sprint starts with the team planning their work by identifying which user stories will be moved from the product backlog into the sprint backlog. Given that a student typically dedicates no more than 10 hours per week to the project, instead of daily scrum meetings, students participate in a weekly scrum during one of the regularly scheduled class meetings. During a weekly scrum, each team briefly discusses their progress made during the past week towards meeting the sprint goal, as well as the plan for the upcoming week. Throughout the sprint, teams maintain an open line of communication with the project partner to make sure that any questions can be answered promptly. At the end of the sprint, each team demonstrates their progress to their project partner during a sprint review when the project partner may accept or reject some or all of the newly developed functionality. Each team also participates in an in-class self-reflection during the sprint retrospectives when they can inspect the results they accomplished, discuss the lessons learned during the sprint, and adapt both the product backlog (to better reflect any possible changes in the project requirements) and the team’s workflow (to make sure that the team does more of what works for them and less of what doesn’t).
Finally, the Transition phase takes place during the last week of the semester. It focuses on knowledge transfer and typically includes the final project demonstration to the project partner and the entire class. There are several possibilities at this point: a) the project continues next semester with the same team(s) (typical for teams in the SE course that will be in the SP course next semester); b) the project continues next semester with at least one new team (same scenario as above, but with an additional team from the next semester’s SE course; or when there’s no overlap in teams); or c) the project is completed and there are no teams actively involved in feature development. These scenarios are illustrated below.
Regardless of the project state, to facilitate the knowledge transfer, teams typically prepare a set of user and deployment documents for the project partner and subsequent project teams. Project continuity is enabled by several factors: a) team staggering so that there is an overlap between a team continuing with the project and a new team, b) extensive knowledge transfer documentation including configuration and build documents, and c) near-peer mentoring where a recent graduate who worked on the same project mentors the next team(s).
SPSG project events and deliverables #
Inception: Project negotiation and proposal #
Type: events + deliverable
During the Inception phase, the instructor collaborates with the project partner to prepare a project proposal. This needs to be a collaborative effort because many potential partners may find it difficult to describe the project scope or explain in clear terms what project outcomes they are looking for.
Project negotiation is an iterative process. We ask all prospective project partners to have a conversation during the initial meeting where they can explain their project ideas and we can provide meaningful examples of completed projects relevant to the partner's operational domain and/or problems they are trying to solve. Such conversations almost always start with a real-time dialog, but then often transition to email, giving more time to provide additional information and answer follow-up questions that are very likely to emerge on either end. Furthermore, the instructor needs to collaborate with the project partner to ensure that the potential project is a good fit using the [SPSG Project Feasibility Assessment Model]{.underline}. Once the instructor has determined that the project is a good fit, we ask the project partner to take a first cut at completing some parts of the project proposal, which is likely to lead to a more fruitful discussion about the project feasibility and the appropriate project scope.
We recommend including the following elements into the project proposal:
Partner contact information
Background information about the partner
Project motivation
Project scope
Project challenges
Constraints and assumptions
Software/hardware/resources provided by the partner
Partner- and project-specific deliverables
Proprietary information
In our experience, well-rounded project proposals emerge after one or more revisions to the initial draft.
Template: SPSG project proposal template.docx
Prerequisites: n/a
Grading rubric: n/a
Elaboration: Team agreement #
Type: event + deliverable
The team agreement, also referred to as a team information sheet, serves several purposes. Requiring the team to create a collaborative agreement prompts them to meet and discuss a range of important questions. This can serve as a good icebreaker, hopefully paving the way for positive team dynamics and rapport. This document will also serve as a “business card” for the team, that can be shared with the project partner before their first meeting with the team. Knowing this helps the team be professional both in the content and in the presentation of the team agreement document.
To help break the ice and get people to talk we suggest the team to have a meal together. During the pandemic, we changed this recommendation to holding an online meeting. Taking an informal picture during the meal or a screenshot during the online meeting would help build the team’s identity and further demonstrate it to the project partner.
We suggest asking students to structure their team agreement by including the following information:
Team introduction: a unique team name, a (formal) group picture of the entire team, and a paragraph describing the strengths of the team as a whole
Team member introductions: an individual picture and a brief biography of each team member written professionally as an introduction to a prospective employer
Contact information: for every team member, list their preferred emails, GitHub IDs, and other applicable contact information (e.g. telephone numbers); identify one team member who will serve as the main contact
The team needs to discuss every aspect of the team agreement in detail and describe all decisions in the deliverable including (but not limited to) the following:
Methods of communication
Communication response times
Meeting attendance
Version control
Division of work
Submitting deliverables
Contingency planning
We encourage the teams to add any other items that they believe may be important.
Template: SPSG team agreement template.docx
Prerequisites:
Grading rubric: Team agreement grading rubric
Elaboration: Project kick-off #
Type: event
As soon as the teams are formed, they are assigned to a specific project. An introductory email sent by the instructor includes two attachments, a project proposal and a team information sheet, to introduce both parties to each other before they meet.
Following that, the project partner meets with their assigned team. We recommend that the instructor attend at least some part of this meeting. This is an opportunity for the team and the project partner to meet face-to-face or online. In case of online meetings, we find it essential to remind students to keep their cameras turned on, at least during the project kick-off meeting. The objectives of this meeting include:
Review project objectives, deliverables, and potential challenges.
Identify a mutually convenient meeting time when the team (or at least most of its members) would be able to meet online with the project partner on a weekly basis. The project partner is again reminded that it is very important for the team to provide an update on the project progress and to discuss any concerns. Having a scheduled meeting occurring at the same time every week ensures the best project outcomes for both the team and the project partner.
Discuss communication policies: typical response timeframe and modality.
Discuss the project schedule with the teams. The project partner must be mindful of the students’ course schedule and their respective deliverables, along with any scheduled tests, school holidays, etc. Thus, it is very important to share an up-to-date course syllabus with the project partner. Similarly, the team needs to be aware of the partner’s schedule.
Template: SPSG introductory email template.docx
Prerequisites: SPSG team agreement
Grading rubric: n/a
Elaboration: Project proposal reflection #
Type: deliverable
To facilitate bridging the gap between the partner’s and the team’s understanding of the project goals and requirements, we ask the team to write their own reflection of the project proposal. This is the beginning of the team’s requirements engineering process. The project proposal reflection consists of three main parts:
Intended use of the system
Overall and project-specific functionality
Main components
We encourage the team to share this document with their project partner before submitting it to the instructor. It is very likely that the partner can point out some discrepancies or omissions, thus helping the team improve their understanding of the project and its scope.
Template: SPSG project proposal reflection template.docx
Prerequisites: a high-level introduction to software requirements and requirements engineering
Grading rubric: Project proposal reflection grading rubric
Elaboration: Requirements outline #
Type: deliverable
This deliverable serves as the next step in the requirements engineering process. The team is asked to have follow-up interactions with their project partner to ask follow-up questions and to verify the correctness of their understanding of any information presented in this deliverable focusing primarily on functional requirements.
Requirements outline deliverable consists of several components:
A narrative providing a general overview of the system's functional requirements and identifying several use cases that focus on the functionality being implemented by the team.
A set of user stories in a commonly accepted standard, each user story corresponding to one of the use cases identified above.
A set of pre- and post-conditions for each user story.
A list of relevant nonfunctional requirements.
A glossary of relevant project-specific terms.
It is essential that the instructor provides an in-depth critique of this deliverable. In addition to providing written feedback, we strongly recommend having a conversation with each team to find out why they made the decisions they made, to learn about their reasoning process in identifying each use case, and their rationale for identifying any epics. It is crucial to correct any potential mistakes at this point. Not doing so will have a potentially strong detrimental impact on the team’s success in the project.
Template: SPSG requirements outline template.docx
Prerequisites: use cases (including UML use case diagrams), agile user stories, functional and non-functional requirements
Grading rubric: Requirements outline grading rubric
Elaboration: Product backlog #
Type: deliverable
This deliverable is essentially a refinement of the previous deliverable, outline requirements. The teams are asked to work with the project partner to set priorities (e.g. high/medium/low or must-have/should-have/could-have). We also ask the teams to estimate the story point size of every item in the product backlog. Having a priority and an estimated size for each user story would enable the teams to identify a set of user stories planned for the first sprint.
The product backlog deliverable includes the following components:
A refined list of user stories with priorities, estimated size, pre- and post-conditions,
A sketch of user interface (as applicable).
Template: SPSG product backlog template.docx
Note: This template assumes that there will be four development sprints in this project, which factors into the sprint size calculations. This should be adjusted as needed.
Prerequisites: introduction to scrum, user story sizing and prioritization
Grading rubric: Product backlog grading rubric
Development: Development kick-off presentation #
Type: event
Note: In a typical SE course where the development phase spans the second half of the semester, this presentation can take place at approximately the mid-point of the semester. Also, this presentation may not be essential in a typical SP course where the development phase spans almost the entire semester.
We found that it is very helpful to have an opportunity for each team to share their experience in requirements engineering with the other teams before they start their development sprints, especially if different teams are working on different projects. In addition to strengthening their communication and presentation skills, an opportunity to present their progress so far also helps the team focus on what’s most important in their project. Furthermore, unlike weekly scrums and sprint retrospectives that also take place in class, the mid-point presentation is much less technical because it focuses on project requirements and gives student teams an opportunity to reflect on their interaction with the project partner. We ask each team to make a formal presentation reflecting the following:
The project, its goals, its problem domain, project users and their needs,
Main functional and non-functional requirements of the project,
Highlights of the product backlog and sprint planning strategies,
Any lessons learned so far about interacting with the project partner, teamwork, and other non-technical aspects of the project.
Template: n/a
Prerequisites:
Grading rubric: Development kick-off presentation grading rubric
Development: Sprint planning & backlog #
Type: event + deliverable
At the beginning of every sprint, the teams are asked to review (and possibly update) their product backlog and, taking into account the priorities, pre- and post-conditions, and story point sizes of every user story, select several user stories for the next sprint backlog. We require the teams to use specialized project management software to maintain their product and sprint backlogs. Our current recommendations include:
Trello – free and very easy to use,
GitHub Projects – free to use professional-grade system, a part of the GitHub ecosystem.
Except for the first sprint backlog (submitted as a part of the product backlog deliverable), each backlog is submitted as a part of the sprint report deliverable.
Development: Standup meeting / weekly scrum #
Type: event, every sprint
A typical student participating in this project is usually a junior or a senior who is expected to dedicate about 10-12 hours per week to the project. They typically take a number of other demanding courses and may have many other responsibilities. Therefore, the industrial practice of daily scrums/stand-ups is hardly applicable in this context. We have adopted a practice of weekly scrums when all team members discuss their progress made during the past week towards meeting the sprint goal, as well as the plan for the upcoming week. Depending on the student load and scheduling, similar scrum meetings can be also held more frequently, e.g. twice a week. We typically run weekly scrums in class to strengthen accountability, provide more opportunity to practice public speaking skills, and to keep the rest of the classmates up-to-date about everyone’s progress, which is especially useful if more than one team is working on the same project. Additionally, holding these scrums in class offers a unique advantage. It gives each team an opportunity to observe and learn from the issues that may arise in other projects, providing valuable insights. The instructor also shares suggestions on how to address or mitigate such challenges. This exposure helps teams better prepare for potential issues on their own projects, fostering awareness and providing strategies they can apply when similar challenges emerge.
Development: Sprint review #
Type: event, every sprint
The team is required to meet with their project partner at the end of every sprint to provide an interactive demo. The intent is for the partner to have the ability to interact with the system, not just watch how the team interacts with it. The partner should review the sprint backlog and reflect the extent to which every feature (user story) planned for this sprint has been implemented. The team reports about this during their in-class sprint retrospective.
Development: Sprint retrospective & report #
Type: events + deliverable, every sprint
Although based on the concept of a traditional scrum sprint retrospective, this event incorporates a number of other elements. At the conclusion of every sprint, each team is asked to conduct their sprint retrospective in class, in front of their classmates. This is done to promote accountability, provide more opportunities to practice communication skills, and to allow everyone in class to learn from the experience of every team. Compared to a traditional sprint retrospective, this event is more like a summary of the actual retrospective that the team had sometime earlier. This format also requires strict timeboxing of this event to ensure that each team has at least 15 minutes to present and answer questions. During the retrospective, we ask each team to address the following:
What was accomplished and to what extent, what were individual team members’ contributions?
What worked well for the team during this sprint?
What didn’t work well and how did you address that?
What are the lessons learned?
Depending on the level and the nature of the course, the complexity of the project, the maturity of students, and the number of teams, some instructors may ask each team to provide the summary of the sprint review along with a brief demo, as it was shown to the project partner.
Each team is asked to submit a sprint report that provides a summary of the sprint retrospective and a sprint backlog for the next sprint. Additionally, we ask the teams to plan their next sprint before they submit this deliverable. This deliverable includes the following components:
User stories completed during the sprint,
Changes to the product backlog going into the next sprint,
Lessons learned during this sprint,
Next sprint backlog.
Template: SPSG sprint report template.docx
Note: This template assumes that there will be four development sprints in this project, which factors into the sprint size calculations. This should be adjusted as needed.
Prerequisites:
Grading rubric: Sprint report grading rubric
Development: Updated code repository #
Type: optional deliverable, every sprint
If the instructor wants to emphasize the code management aspect of the project, the end of every sprint could be an opportunity to examine the team’s or each individual teammate’s levels of contribution to the codebase.
Transition: Project demonstration #
Type: event
A final demonstration is a vital element of any course project. Each demonstration should be accompanied by a brief presentation explaining the nature and the specifics of the project. In our practice, a project demonstration replaces the last sprint retrospective. As a result, we ask for the presentation to specifically discuss the lessons learned by the team during the last sprint, as well as the main lessons learned throughout the entire project.
Template: n/a
Prerequisites:
Grading rubric: Project demonstration grading rubric (Note: project demonstration grade will reflect the quality and degree of project completion)
Transition: User manual #
Type: deliverable
This deliverable should be customized based on the specific needs and expectations of the project partner. Generally, we ask the teams to produce a deliverable reflecting the main features of the system and providing several detailed walk-throughs through the system illustrating how different tasks can be accomplished.
Template: SPSG user manual template.docx
Prerequisites:
Grading rubric: User and deployment documentation grading rubric
Transition: Deployment / transition documentation #
Type: deliverable
This deliverable is intended to assist with the knowledge transfer to the next team that will continue working on this project, whether they will be adding new features or addressing routine maintenance tasks. At this point, there are several possibilities for the project’s next phase:
The project continues next semester with the same team(s). This is typical in a program that consists of a two-semester capstone project sequence.
The project continues next semester with at least one new team. This could be the same scenario as above, but with an additional team (or several) from the next semester’s first course in the capstone sequence, resulting in an overlap in some teams. There will be no such overlap in an academic program where the project is associated with a single course, and the project will continue with one or more new teams.
The project is completed and there are no teams actively involved in feature development. The project might still need routine maintenance and bug fixes.
This deliverable will need to detail all necessary steps needed to deploy/install/configure the software developed for the project, along with the development environment configuration. Additionally, this deliverable should require that the code base be reasonably well documented, and that the instructor (or another designated person) be granted access to the team’s code repository so that it may be properly archived.
Template:
Prerequisites:
Grading rubric: