Outcomes
Given a general course description and goals, produce a detailed design document that makes clear the following:
- Desired outcomes and capabilities
- How those outcomes will be assessed
- Suggested learning activities
- A grading scheme for the course
Introduction
Throughout this course you will work with a small group of peers to produce a single course design document for a CS course targeting an age-appropriate audience of your choosing. You will use the Understanding by Design (UbD) process reviewed during Week 2.
Grading for Equity calls for grades to be based on individual work as much as possible, not group work — and that makes sense. My goal is to assess your learning, which isn't always visible in a group deliverable. For that reason, this project generates five assessments that contribute to your final grade:
- Your group's final deliverable (one grade assigned to the group as a whole)
- Individual Reflection #1 (Competency 8) — on your team's outcomes
- Individual Reflection #2 (Competency 9) — on your team's assessments
- Individual Reflection #3 (Competency 10) — on your team's learning activities
- Individual Reflection #4 (Competency 11) — on your team's grading scheme
Getting Started
The project is organized into eight sections described below. A template design document is available in Google Drive for your team to copy and label as your own:
Have one team member copy the template into the shared folder and label it with your group's name before you begin.
Project Sections
1. Course and Audience Description (Due Sunday, June 21)
I have grouped you with classmates who share an interest in a similar type of course, but it is important that everyone — you, your teammates, and me — is clear on exactly what course you are designing. Begin the document by answering the following questions clearly and in enough detail that a reader unfamiliar with your group could understand your course. A short bullet list is not enough; aim for half a page to a full page of written description.
- What would the course catalog description look like?
- How long is the course (semester, yearlong, major unit, etc.)?
- Who is the target audience (grade level, required or elective, etc.)?
- Are there prerequisites?
- Will this course serve as a prerequisite for later courses?
- Is this a standalone CS course or integrated into another subject?
2. Course Outcomes (Due Sunday, July 5)
Using the Iowa/CSTA CS Standards as a starting point — not a limitation — generate a list of the outcomes you expect students to achieve in this course. This section drives the entire design process, so take it seriously. As a team, discuss which topics belong in the course and what mastery looks like for each. Organize the outcomes in whatever way fits your course, but make sure the structure is clear.
Don't underestimate the scope here. Think at the high level (standards), but also break those down into the medium and lower level outcomes you expect from students. I am giving you two weeks on this to signal how much effort it warrants.
You may find this list of Bloom's Taxonomy verbs for computing helpful when writing outcomes.
3. Course Assessment (Due Sunday, July 5)
Once you have a solid set of outcomes, identify how you will assess whether students are meeting them. Assignments, projects, quizzes — yes, but more specifically: what will a student need to know, do, or demonstrate to convince you they have met each outcome?
I think of assessments as a separate body of content from outcomes. You need a strong grasp of your outcomes before you can design meaningful assessments. That said, some teams find it useful to present outcomes and assessments in parallel rather than in sequence. Either approach is fine as long as it is clear to the reader what is what.
4. Course Schedule (Due Sunday, July 12)
Create a general schedule that distributes topics, outcomes, and assessments across the length of the course. Are these four equal units? One long unit and two short ones? Whatever you propose, it should be clear to an outside reader what you are planning and in what order.
5. Learning Activity Descriptions (Due Sunday, July 19)
What will students actually do to learn the material? Lectures, videos, projects, worksheets — likely some combination. For each week in your schedule, describe the activities well enough that a reader understands what each one is about and could start building it themselves. I am not looking for full lesson plans at this stage, but more than a bare list of activity types.
As you work through this section, keep supportive practices in mind. What decisions can your team make to help all students feel engaged and welcome?
6. At Least Two Specific Lesson Plans (Due Sunday, July 20)
Split your group into two smaller teams and each fully write up one specific lesson from Section 5. I encourage — but don't require — choosing two lessons in different styles. The format is up to you; use whatever fits your school district's expectations. If you want a reference point, look at how Code.org structures their lessons:
The goal is a lesson plan that is close to ready to use as written.
7. At Least One Specific Assessment (Due Tuesday, August 4)
This can be a whole-group effort or assigned to one person and edited by the group. Choose at least one assessment from Section 3 and produce the actual handout or instrument you would use with students. Format it however is appropriate for your course.
8. A "Syllabus Quality" Grading Policy (Due Tuesday, August 4)
How will you assign final grades? Describe how all of the elements from the previous sections — activities, assessments, participation, and so on — combine into a final letter grade. "Syllabus quality" means there should be enough detail that a classmate or I could open your gradebook and assign grades that match your intentions. See the grading section of our course syllabus as a reference for the level of detail I have in mind.
You are not required to follow my format or adopt equitable grading practices, but I strongly encourage you to at least make a conscious team decision about whether or how you are addressing equity in your grading scheme.
Submitting the Project
When your team is ready for me to grade the project, have one member email me confirming that the document in your group's folder in the Group Projects folder is complete and ready for review.