Experiential Learning and Research Track
Instructor Onboarding Toolkit
Overview
So, you have a project, and you would like to recruit students using the new ELR track to work on it. Fantastic! We appreciate your engagement with ELR, and look forward to helping you recruit and maintain a great team.
The purpose of this document is to help familiarize you with the structure of the ELR program, and to provide you with some guidance as you prepare your project to be ready for integration with ELR. While 1-1 consultation is also available to help resolve any questions or discuss specific wrinkles in your particular project, we have endeavored to provide answers to the most common questions in this toolkit.
Timing
In order to effectively plan the number of seats that we will include in each semester’s offering of 302/303/402, new projects will need to be submitted to the SEEL (Student Engagement and Experiential Learning) committee prior to enrollment opening in the next semester (October for spring kickoffs, and March for fall kickoffs). Preference will be given to projects that have an anticipated longer-term horizon; ideally, the project will be able to support students working on it for a minimum of three semesters. Note that there is no limit to how long a project can run - if you have an effort that can benefit from five years of engagement, we are happy to support it.
Team Size
While it is possible to have small projects (less than 4 students per semester), the greatest benefit to the students exists in projects that can support larger teams (4 or more students), ideally with students who have a mix of experience on the project. As part of the onboarding process, we will need you to tell us how many students the project can support, and what roles it can support (see Team Composition below). Team sizes of four or more will be eligible to have a project manager (see “Working with student project managers” below) assigned to help with logistics, based on availability. If the team size is less than four, you will need to play the role of project manager yourself, with the attendant tracking of deliverables and status. It is possible to change the team size from semester to semester, but if you want to do so, you need to provide notice to the ELR coordinator prior to enrollment for the semester in which you would like to enact the change.
Team Composition
Along with the number of students that the project can support, you will need to define the different levels of responsibility that you can support in the project. Each ELR course covers different ground in terms of the overall learning objectives for students, and it’s important that we understand what roles are available. All of the courses assume that students will have project deliverables to complete, but the nature of those deliverables, and how they will work with their peers, differs slightly from course to course. This is particularly important if you want to offer the capstone option (detail can be found in the syllabus for 402), as there are additional requirements involved in offering a capstone course.
| Course | Targeted Population | Unique Outcomes | Required Content |
|---|---|---|---|
| 302 | Sophomores, Juniors |
|
|
| 303 | Juniors, Seniors |
|
|
| 402 | Seniors |
|
|
Team Selection
Unlike independent study or research, since EL/R is a course that students can enroll in like any other, you may not have any influence over which students join your project. You need to be prepared to accept students who will need more mentoring, or have less robust backgrounds, than those who you hand-select in the traditional independent study model. This is not to say that we will not take student and instructor preferences into account as far as that is possible! It does mean, however, that we cannot give preference to any particular student in enrolling in the course, nor can you refuse students assigned. If a student is enrolled in the course, and they are very interested in your project in particular (they may already have spoken to you, or worked with you in the past) we will give preference to assigning those students to you over those that have no preference.
Training
If success in your project requires skills that students do not currently have, you will need to have a plan for training them in the areas in which they will need to become proficient. This may include a set of resources to read, example code to build, or other materials to prepare. You should also have some way of evaluating this training that the project managers can follow up on. For example, if you need your team members to have knowledge of SQL, you may need to have an SQL tutorial that you recommend, and a test database that they will have to answer some questions about via querying to show that they have mastered that material before moving on to writing SQL in the project.
The only prerequisites for 302 are 220 and 250, so you can expect a knowledge of programming and data structures, but should not expect any specific languages, frameworks, or background beyond that.
Requirements
During onboarding, and again at the start of each semester that you run an EL/R project, you will need to determine what the goals are for the team as a whole during that semester. All software development cycles start with defining requirements - and while the project managers and team can help clarify, prioritize, and suggest improvements or alternatives, you are the one who needs to set the vision and overall objectives. While it is possible (and likely!) that these may change somewhat during the course of the project, you need to start somewhere, and the more work you do to establish a clear set of goals, the more likely you are to end with a successful product. If this is the first time you are working with an EL/R team, there are some guidelines that may prove helpful in starting the process.
Requirements should be stated in a “User Story” format, which is just a template that helps focus on who needs a particular feature and why. A user story will be
As a <particular type of stakeholder> I want to <do a particular thing> so that <I achieve a particular goal>
This helps you ensure that the requirements are focused on the people who will be using your software, and that the team knows what the motivation for the feature is, and how to measure success (the goal will be accomplished). An example may help, this is the set of requirements used in CSE 370 for teams building a social media platform.
You should have enough stories defined to keep your team busy for the semester; depending on the complexity of the features and the background of the team, this number may vary widely. It’s best to define everything you can think of in a perfect world, and then let the project manager and the team work through what is practical in the time allotted.
If you want to hold a requirements gathering session to help you get used to this format, you can ask for this during the onboarding process, and we’ll be happy to help!
Working with Student Project Managers
If your project is assigned a project manager, while there are many benefits, there is also an obligation to make yourself available to the PM to help them guide the team appropriately. The project managers are also students, with all the variability and potential for unexpected behavior that entails! They will need information from you on project rules and restrictions, required deliverables, tools and techniques, and overall goals; their role is to hold the team accountable, but they cannot do that without your input into what the expectations are! While you do not need to schedule regular meetings with the project managers, it is helpful if you meet with them at the beginning of the semester to explain the goals and purpose of the project, and to make sure that they have access to any relevant documentation that they will need to manage the team effectively.
Project Management Role
The project manager will fulfill several functions in helping get your project delivered. The first is that the project manager will meet each week with the project team, and review the tasks that they were supposed to deliver that week, and assign new work. They will help avoid dependencies, navigate merge conflicts, and ensure that the team stays busy and is meeting their commitments. The second thing that the project managers will do is provide sprint reviews for each of the “chunks” of development planned. There are four sprints in a semester, and at the end of each sprint, the project managers will use a rubric to assess the teams progress against the overall goals for the sprint. Finally, the project managers will ensure that project documentation is current and correct; they will help guide the way that source code management is done, and make sure requirements and tests are unambiguous and effective.
Course Structure and SDLC
In order to provide a consistent structure to the projects, they will follow a normalized software development lifecycle (SDLC) that breaks up the semester into regular checkpoints, with expectations for each.
Technology and Tooling
In order to provide assessments and track progress, there needs to be a standardized set of tools that allow students, project managers, instructors and reviewers to organize, maintain, and evaluate project goals.
Source Code (GitHub)
GitHub is the standard repository for project source code. This is partially because it integrates into other project management software, and partially because students are all familiar with it from earlier courses. If you have your source in a different place, options will need to be discussed with the ELR coordinator.
Requirements and Testing (Trello)
Trello is a tool that integrates with GitHub repositories to provide a scrum board style organization for requirements. This allows the team to establish and track requirements in an industry standard format through the development process, from planning to coding to testing to implementation. Requirements are typically gathered in a “User Story” format, and decomposed into technical tasks for the team to implement.
User Interface Design (Figma)
Figma is an industry standard tool for building interactive wireframes, and it supports academic licenses and multiple editors. If your project has a graphical user interface, it is strongly suggested that the interface be designed or enhanced in Figma by the team before any coding begins. In the event that your project does not involve a graphical interface, a separate mechanism for design can be substituted, but this will need to be part of the onboarding process.
Additional Elements
Your particular project may have other tools or technology required, and identifying this and providing the appropriate training and access will be part of the onboarding process.
Contact Hours
Lectures
CSE 302 Students will have a limited lecture section that meets once a week. This will be taught by the ELR Coordinator, and will focus on the basics of software engineering and teamwork. CSE 303 will have an in person or video lecture component, which will be provided by the ELR Coordinator. CSE 402 will not have any lecture component associated with it.
Weekly Project Meetings
It is assumed that you will invite the students to your regular project meeting(s). If you do not have a weekly project meeting, you will need to schedule one. If you are not assigned a PM, you can combine this with the weekly team meeting below.
Weekly Team Meeting and PM Review
Each week, the team(s) will meet with a project manager (PM) for 30-50 minutes. For larger projects, and assuming that enough managers are available, this will be a student PM assigned to the team. For small projects, this will be the instructor. The primary purpose of this meeting is to review the tasks that were assigned to each team member in the previous meeting, and to assign new work. This is also a time to brainstorm, ask questions, review alternative designs, discuss roadblocks or problems, and propose new ideas. Project managers will send out minutes from each weekly meeting (there is an in-house piece of software to help with this).
Sprint Review
At the end of each sprint, there will be a review of the team's performance and progress. Ideally, the review will be performed by someone other than the project manager, as that will help bring an objective external focus to the evaluation. If you have an assigned PM, we will also assign an evaluator for each sprint. There is a standard rubric for evaluation developed for the software engineering capstone, but it may be that you need to evaluate other areas; if the standard rubric is not appropriate to your project, developing a suitable rubric will be part of the necessary onboarding process. The week prior to the sprint review, the team needs to have the work done during that sprint available to present in some format; this may vary depending on the type of project, but it is necessary that for each sprint they have some concrete evidence of completed progress towards the project goals for the semester. If the project involves them writing code, they need to be able to execute this code and explain what their demo is doing and why.
Demo Day
At the end of the semester, the project team(s) will present their work at CSE Demo Day. This is an event held on the last day of classes in the Davis Hall atriums. Each team will get a table to set up their material (poster and demo), and judges from local industry and department faculty will provide feedback (and awards) to the top teams.
Calendar
| Week | Activities |
|---|---|
| Week 01 | Introduction, Teambuilding, and expectations |
| Week 02 | Onboard new team members |
| Week 03 | Weekly team meeting and PM Review |
| Week 04 | Weekly team meeting and PM Review, Deploy to evaluation environment |
| Week 05 | Sprint 1 Grading |
| Week 06 | Weekly team meeting and PM Review |
| Week 07 | Weekly team meeting and PM Review, Deploy to evaluation environment |
| Week 08 | Sprint 2 Grading |
| Week 09 | Weekly team meeting and PM Review |
| Week 10 | Weekly team meeting and PM Review ,Deploy to evaluation environment |
| Week 11 | Sprint 3 Grading |
| Week 12 | Weekly team meeting and PM Review |
| Week 13 | Weekly team meeting and PM Review , Deploy to evaluation environment |
| Week 14 |
|
Assessments and Deliverables
There are several ways in which both individuals and teams will be assessed. Each week, during the weekly meeting with the project managers, students will be assessed both on attendance (meetings are mandatory) and on completion of the tasks assigned for that week. Each sprint, the team will be assessed jointly on their compliance with the sprint rubric. For most projects, this will include best practices like following standard formats for requirements, creating comprehensive test plans, and using good version control practices, but there may be alternate things assessed on a per project basis. They will also participate in a peer and self evaluation, and (in the event that there is an assigned project manager) an evaluation of the project manager. At the end of the semester, the teams will have presentations on their work that are evaluated by the instructor and by the judges at demo day. If the student is a 402 student, they will also have to have a presentation to you about their work, and also some artifacts outlining their exploration of the legal and ethical impacts (real or potential) of the project. You will be responsible for uploading any examples of these deliverables as necessary for accreditation reviews.
Grading
Given the distributed nature of the program, the ELR Coordinator is the instructor of record for the classes. As the project leader, however, the responsibility for assigning grades to the students is up to you! For midsemester and final grades, you will need to provide a CSV file of ubit names and grades to the ELR Coordinator for upload into HUB.
Teaching Credit
For each 30 students that are mentored in project teams, instructors running these projects will be eligible for one course release. The specific details related to the timing of the course release will be subject to coordination with the course scheduling staff and the chair.
Project Closure
When a project comes to its conclusion (perhaps the grant is out of money, or you have accomplished all of your objectives, or you have decided to move on to other efforts, or you simply don’t want to continue with it as an ELR option) we need to know by the middle of the final semester that you will support students. This will give us time to discuss potential projects to move students to, if they would like to continue in the ELR track, and allows us to add project retrospective deliverables to capstone students who may be participating, as well as assigning closure deliverables to all student participants. Failure to provide adequate notification will result in that project not counting towards the teaching credit totals.
Additional Support
Whew, there is a lot to think about here! Especially if this is your first engagement with ELR, it can be a bit overwhelming in what is certainly a busy schedule. To that end, we’re happy to provide 1-1 consultation with the ELR coordinator during your onboarding process, to answer questions, disambiguate gray areas, talk about how your project will fit in, and just generally help ensure that you are ready to bring on your new project team.
Documents
The documents section of this website contains many additional helpful documents that can help you understand the expectations for both the teams and the projects.
Onboarding Checklist
- Rubric for sprints
- Weekly meeting tasks (run grader? Run automated tests?)
- Define any limitations (tech stack, new code, code reviews?)
- Define any specific technology needs
Semester Checklist
- Onboard PM (if assigned)
- Schedule meetings with project team
- Review rubrics and onboarding tasks for changes
- Provide grades and assessment materials to ELR Coordinator