Planning begins with a learning goal, and the first task is to understand the goal well enough to teach toward it. That understanding works at several levels of scale. At the smallest, a goal has to be taken apart into the knowledge and skills it contains. At the level of a single lesson or unit, it has to be written as an objective precise enough that you could tell whether a student met it. At the level of years, it sits in a progression of standards, with foundations before it and more advanced work after. And at every level it has to fit the particular learners, whose age and development shape what kind of work makes sense. This section moves through those levels in turn.

Taking a goal apart#

To unpack a learning goal, identify the specific knowledge, skills, and vocabulary it requires, separating what students must know from what they must be able to do. One useful question drives the process: what would a student need to know and do in order to show this? Take a goal in which students write a program that awards a bonus when a player's score passes a threshold. Students need to know what a condition is, what comparison operators do, and that a comparison produces a Boolean value, true or false. They must be able to change a stored value when a player earns points, which is a performance and belongs in the "do" column. Nothing in the goal requires loops, arrays, or functions, so a careful unpacking also shows what can be left out. A list of what students should know is easy to write and often incomplete. Planning notes for a debugging goal that list the relevant vocabulary and concepts but never mention the skill of finding and correcting an error in a faulty program have left out the heart of the goal. Materials and tools matter for planning, too, but they come later, since they aren't what the goal requires of students. Unpacking also exposes demands that hide behind familiar topics. A goal about evaluating data visualizations requires knowing chart types, and it also requires judging how a design choice, such as a shortened axis, changes a reader's conclusion, which students will need to practice.

A framework for what K-12 computer science goals contain makes this kind of unpacking easier. The K-12 Computer Science Framework describes CS learning as a combination of concepts, the ideas of the field, such as loops, conditionals, and binary representation, and practices, the things computer scientists do with those ideas, such as debugging, testing, and collaborating.¹ Good goals combine the two, so a good objective names what students will do with a concept. "Students will correct a faulty stopping condition in a program that uses a loop" joins a concept, loops, with a practice, debugging. An objective that names only the practice, such as "students will debug programs," leaves unstated which computing ideas students are to use, and one that names only the concept leaves out what they will do. In a unit where students work with a partner to write and test programs using conditionals, conditionals are the concept, and collaborating and testing are practices. Wording doesn't decide the category: a concept is still a concept when phrased with an action verb, as in "students will explore arrays." The distinction also helps diagnose instruction. If students can state what a loop does but can't use one, instruction has probably stressed the idea and given too little practice in applying it.

Writing a measurable objective#

Once the goal is unpacked, it can be written as an objective that says what success looks like. A strong objective uses an observable verb, states the conditions and the expected performance, and is appropriate to the grade band. Observable verbs name actions that produce something you can examine. "Trace the value of the counter during each pass" produces a record, while "understand," "appreciate," and "know" describe internal states that have to be inferred. The conditions are the circumstances of the performance, such as the starting materials students receive, and the expected performance is the standard that counts as success. Compare "Students will understand arrays" with "Given an unsorted array, students will write a loop that returns its largest value on all test cases." The second has an observable verb, a stated condition, and a level of performance. Similarly, "Using a provided data set, students will create a bar chart with both axes labeled" gives the materials, an observable action, and a checkable criterion, while a draft asking students to "explore" charts and make them "clear and attractive" doesn't show how a result would be judged. Objectives also describe what students will do, not what the teacher will do, so "the teacher will demonstrate sorting" is a lesson activity and not an objective. Finally, an objective can be observable and precise and still be wrong for its students, if the expected performance is too advanced for the grade band.

Placing a goal in a progression#

No goal stands alone, because students reach it from somewhere and go on to something else. The New York State Computer Science and Digital Fluency (CS&DF) standards progress across grade bands, so the standards in a concept form a learning progression, a sequence showing how an idea develops from early grades to later ones.² Looking backward in the progression, to earlier standards in the same concept, helps identify prerequisites. Looking forward shows where learning is headed and what the current work should prepare students to do. If a middle-school standard asks students to write programs with loops and events, a later standard may ask them to organize repeated code into functions with parameters, adding abstraction to the same foundations. When students lack a foundation, the progression shows which one, and the teacher can use earlier-band standards to identify what is missing and teach it in service of the goal, without abandoning the goal itself. Progressions also help at the scale of a school or district. Mapping each course to the standards reveals gaps, where a standard is never taught, and unnecessary repetition, where several courses teach the same thing at the same level. Concepts can and should return across grades, but they should deepen each time they do.

Fitting the goal to the learners#

The last level is the students themselves, because the same concept looks different at different ages. Early grades may approach sequence and debugging through unplugged activities, stories, and block-based tools, all of which avoid depending on reading and typing.³ Young students can learn sequence by ordering picture cards that show the steps of a morning routine, and they can practice debugging by finding the step that sends a floor robot off course, a concrete, physical task. These approaches make real computer science accessible before students can type fluently, which is different from simply having young students use apps, since using apps isn't the same as learning computer science. Older students can work with text-based languages and abstraction, and they may find tools designed for young children off-putting. A high school class that has learned with blocks can move to a text-based language while keeping supports such as starter code to ease the transition. With a goal unpacked, written as an objective, placed in a progression, and fitted to the learners, the next question is where these particular students stand in relation to it, which is the subject of 0005.b.

• unpacking: identifying the knowledge, skills, and vocabulary a goal requires
• concepts: the ideas of computing, such as loops and conditionals
• practices: what students do with concepts, such as debugging, testing, and collaborating
• measurable objective: an objective with an observable verb, stated conditions, and an expected performance
• observable verb: a verb naming an action that produces examinable evidence, such as trace or write
• conditions: the circumstances of a performance, such as the materials provided
• expected performance: the standard that counts as success
• learning progression: a sequence of standards showing how an idea develops across grade bands
• CS&DF standards: the New York State Computer Science and Digital Fluency standards

Practice: practice questions for 0005.a

1. LAI 516, Standards: K-12 CS Framework: concepts and practices. ↩

2. LAI 516, Standards: NY CS&DF. ↩

3. LAI 516, Scope and sequence: early childhood, elementary, and middle-school CS. ↩