Skip to content
This repository has been archived by the owner on Aug 13, 2024. It is now read-only.

Latest commit

 

History

History
49 lines (42 loc) · 4.75 KB

File metadata and controls

49 lines (42 loc) · 4.75 KB

Lesson 6.2 - Brainstorming and Evaluating

Learning Objectives

Students will be able to...

  • Identify factors to use when choosing between project ideas
  • Rank a group of proposed project ideas using the identified factors

Materials/Preparation

Pacing Guide

Duration Description
5 minutes Welcome, attendance, bell work, announcements
10 minutes Review process and identify first steps
5 minutes Brainstorming
10 minutes Pitch writing
20 minutes Peer review
5 minutes Debrief and wrap-up

Instructor's Notes

  1. Review
    • Ask students to identify the steps in the design and planning process as discussed in Lesson 6.1.
      • Remind students that all steps are vital, and that thorough and thoughtful planning and design can make the coding phase much easier.
    • Inform students that today they will take the first steps in designing their final project.
  2. Brainstorming
    • Give students 3-4 minutes to brainstorm and write down as many project ideas as they can. This should be done mostly in silence.
      • At this point, there should be minimal detail, no evaluation or rejection of ideas, and no discussion. In particular, students should not think about the difficulty or "coolness" of the project yet. Just write down ideas.
      • If desired, have each student share one idea. Do not allow discussion, criticism, or explanation-- each idea should be summarized in only a few words or a single sentence.
  3. Pitch writing
    • Have students look at their list of ideas and spend a few minutes thinking about them. Then, each student should pick their 3 favorite ideas and write a "pitch" for the project. A pitch should be no more than a short paragraph and should describe the basic, high-level features of the project. The pitch should not include any implementation details (scripts, sprites, etc.).
      • Pitches should include a moderate level of specificity-- enough for someone to imagine how the app will work, but not so much to get bogged down. Enforce the "one short paragraph" restriction.
      • If a student is having difficulty developing a pitch for an idea, that might be a sign that the idea is not fully-formed enough to be a final project.
      • If a student is having trouble keeping the pitch short, the project may be too complex to complete in the available time.
  4. Peer review
    • Pair students up and have students take turns reading one of their pitches to their partner and asking for feedback. Partners should ask questions to help identify both the best and worst parts of each pitch.
      • Remind students to keep all feedback constructive, respectful, and professional. Students should not criticize each other's ideas, but can point out potential concerns.
      • Students should take notes during their conversations and refine their pitches based on their partner's feedback and their own realizations.
    • If time allows (or over the course of multiple days), repeat this process with new partners.
  5. Debrief
    • At this points, students should have between one and three pitches that are well-defined and reasonably well fleshed-out. Overnight, students should consider their pitches and rank them in order or which they would most like to pursue as their final project.
      • Make sure students don't just pick the "coolest" sounding idea, but also consider the technical challenges, amount of time available, and their own interest in and willingness to see the project through to completion.

Accommodation/Differentiation

  • If students are having difficulty coming up with project ideas, encourage them to think about existing software. While simply recreating an existing app should be a last resort, thinking about apps they already know can help students come up with functionality they might like to include.
  • If your class is fairly self-sufficient and mature, you can consider allowing students to "borrow" an idea from a classmate if they find one they like better than any of their own. Make sure the person who had the idea is OK with it being borrowed, and emphasize that the students must each build their own version.
    • This can be a bit dangerous, as it puts the student somewhat behind in the process right from the start, since they won't have as much context having not written the pitch themself. Consider carefully whether this is a good idea.
  • Encourage each student to pick a project that fits his or her level of technical skill. Make sure students are not overcommitting and choosing projects they do not have the skills to complete. Also try to discourage stronger students from choosing simpler projects in an effort to do less work.