Notes for SDL Instructors

Overall structure of SDL:

• Fall term: establish scope & epics, build prototypes, run a first sprint
• Winter: run three sprints, including CI by the second, with a goal of delivering an evaluation version by the 2nd or 3rd sprint.
• Spring: three more sprints, incorporating feedback from evaluation version. Final delivery by end of school year with an effective CI system.

The expectation is that by the end of each term, all code meets standards, designs are documented in diagram form, and all work in progress has been merged into the master branch and that all other branches have been closed.

One thing that is not included is a formal user evaluation. Student teams in SDL do not have the resources for such tests. They may be able to run informal tests with small groups of students, but full evaluation with larger groups must be done by the client.

The bulk of the students take SE 3010 in the fall, 3020 in the winter, and 3030 in the spring. However, students start the sequence in any quarter and can have gaps between the courses. As a result, SE 3030 students may be taking the course at the same time as some SE 3020 students. Generally students follow the syllabus of the dominent group of students; all students will follow the SE 3020 syllabus in the winter term even if it is the first or last term in the sequence for some students.

General Instructions

• The primary responsibilities of each instructor is to keep the team engaged in the project, performing ceremonies as appropriate, and motivating the team to be responsive to the client. Instructors also validate the work to ensure high quality.
• Instructors organize the first meeting with clients. Teams will organize later meetings throughout the year. The expectation is that teams will meet with clients at least once a sprint and often twice a sprint, especially in the fall. Video conferencing can be used for meetings if it is more convenient to and preferred by the client.
• When clients come on campus, call campus security close to the date they will arrive and give them a license number.
• Generally, the product owner proxy (POP) role is assigned for the full year, but this can be rotated if the instructor agrees.
• All other team roles are rotated on a regular basis so that each of the other team members receives experience with each of the roles (other than POP).
• The team, rather than the product owner, is expected to write all PBIs. Product owners are to review and prioritize PBIs. Assigning story points to each PBI is the responsibility of the team.
• A key method for confirming contributions by each team member is to examing commit and time logs. It is important that both provide meaningful information to ensure instructors have visibility to what was accomplished. In particular, quality commit messages will help instructors distinguish between trivial changes and substantial commits that need to be reviewed.
• It is expected that spike PBIs in the second fall sprint will focus on the technologies involved in the project. They should generally not include elements of the project; that is, they should not relate to any project-specific PBIs that are the subject of the third fall sprint.
• Create a group for each SDL team, giving all students Maintainer access. Creating groups ensures each team can set up epics (since they are global to the group). The group should be in gitlab.com/msoe.edu/sdl/y20sdl (or other group, depending on the year).
• Within each group, create a project with a readme. Students need Developer access. It is advisable to set the expiration date to August of next year so it is clear who is contributing to the project.
• I typically make sprint reports/reviews due at least a few days after the end of the sprint. Students should not do the review or retro during lab time once the sprint is finished; that time needs to be reserved for finalizing the sprint backlog and getting started on the next sprint.

SE 3010

• First week:
  • Organize meetings with clients. I talk to the students for the first hour of the first day, so I arrange the meetings for the 2nd hour or the 2nd day. Send email with the client's make, model, and license number to PublicSafety-Staff (with a reason) so they can park on campus.
  • Ensure all teams are using the same project tracking tools. Any differences will soak instructor time in finding appropriate materials.
  • Ensure all teams are using the same repository tool, again for critical functionality. Clients are free to move the work to another repository when the project is finished. Clients should not be committing changes to the repository without your approval, so any access should be read-only. If clients do work, it can be hard to assign credit and often clients introduce errors or complexities that make it harder for the team to take ownership.
  • Ensure there is a single repository for each project. Multiple repositories simply mean instructors have more places to look for project and process evidence. This increases grading effort with little benefit. Separate repositories for spikes can be helpful if approved by the instructor.
• Technology assignments:
  • These are to be individual; students can help each other, but all code will be independent and not related to the project.
  • If projects include concurrency, prioritize building concurrent applications in the target language. This likely includes discussing the concurrency issues with teams, even if that material will also be covered in Operating Systems.
  • Have each student document the goal, technologies tried and used, how to build the system and test that it works, and lessons learned.
  • The bulk of the work will be done outside SDL time. This works for the first sprint in the fall because most other PBIs will be ones that the team needs to work on together during lab time.
  • Each student is to schedule demonstration time in the instructor's office. NO demos during SDL lab time, and do not demonstrate these to your product owner.
  • Graded on 30% functionality, 30% for getting the work done (on time, by the end of the sprint; may allow late penalties), 30% for documentation.
• 2nd sprint:
  • 25% of the grade is to be on the lessons learned around the spike solutions, and these lessons must be documented and included (verbatim) in the sprint report. Quality of this documentation is a major part of the sprint grade.
  • 10% of the grade is to be on PBIs for sprint 3:
    • Is the description sufficient to understand the problem area?
    • Do PBIs for stories use the standard form, "as a ___, I would like to ___ so that ___." ?
    • Do PBIs have acceptance criteria using the given/when/then format?
    • Is the PBI sufficiently constrained that teams cannot keep adding new criteria?
    Note we are not checking for automation at this point.
  • 10% of the grade is to be based on the quality of diagrams.
• Sprint 3
  • Ensure that people assigned to tasks are not those working on that task for the mockups.
  • Emphasize that a significant portion of their sprint 3 grade will be based on their contributions and pull requests. People without pull requests will not get As or Bs.
  • Emphasize that PBIs are not assignments:
    • They must submit pull requests when they have significant portions done, even if the full PBI is not ready for review.
    • POPs are absolutely expected to validate PBIs to move them to Done; only show PBIs to clients if the team believes they are done. The primary role of the product owner is to attend the review and set priorities for future work.
    • Have teams demonstrate all functionality to the instructor before demonstrating it to clients. Ask the team what can be improved about each PBI.
    • Last minute commit-storms will result in a 5% grade reduction.
  • The quality of the sprint report will be 30% of the sprint 3 grade. The report must make it clear what was accomplished and by whom, how many hours were worked by each student (accurately! students are also responsible for recognizing overlapping times and time entries with no description), that successes are noted by indiviual, and that process goals contain numbers indicating measurable improvements.
  • Hold a formal, 45-minute retrospective with each team outside the SDL hours. (Teams will often do their own retrospectives in future dates, but this one must be done with the instructor.)

SE 3020

TBD, but three sprints largely evaluated as the third sprint for SE 3010.

SE 3030

TBD, but three sprints largely evaluated as the third sprint for SE 3010.