Discovery · Systems Project 14
Plans and Feedback
Everything takes longer than you think. Then somebody tells you what you missed.
Student PIN:
Try It — Guess, Then Time It
Before you do anything, write down how long you think each of these will take your team. Guess in minutes.
Then actually do them, and time them.
| Task | Our guess | Actual | Out by |
|---|---|---|---|
| Write a program that drives forward one foot and stops | |||
| Take the claw off and put it back on | |||
| Score any one mission three times in a row |
| Question | My answer |
|---|---|
| How many did you guess too low? | |
| Which was furthest out? | |
| What took time that you had not counted? |
Almost Everybody Guesses Too Low
Not because people are bad at math. Because when you picture a job, you picture it going well — you do not picture the bolt rolling under the table or the program not compiling.
Professional engineers get this wrong too. The fix is not to guess better. It is to write the guess down, then find out how wrong it was.
Learn It — Timelines and Honest Answers
A timeline is a list of what has to be done, in order, with a time against each one.
Each thing that must be finished before the next can start is a . Milestones are how you find out you are behind while there is still time to do something about it.
| A timeline gives you… | Which matters because |
|---|---|
| An order | Some jobs cannot start until another is done |
| A time for each | You can tell early whether you are behind |
| A name against each | Everyone knows what is theirs |
| Slack | Something always goes wrong, and a plan with no room breaks |
⚠ One Late Task Is Not One Late Task
If the claw is not built on time, the person who was going to program the claw cannot start either. A delay in one place moves everything downstream of it.
That is why you say something the moment you know you will be late — not when the deadline arrives.
Feedback
is somebody telling you what they actually saw, so you can make the thing better. It is not the same as being marked, and it is not the same as being criticised. Giving it
- Be specific. “The turn ” is better than “it does not work”.
- Talk about the work, not the person.
- Remember how long they spent on it.
- Say what is good as well. You are not being kind, you are being accurate. Receiving it
- Listen to all of it before you answer.
- Ask a question if you do not understand.
- They want you to succeed. That is why they bothered.
- You do not have to take every suggestion — but say why not.
The end user
The is whoever the thing is actually for. Not you, and not your teacher marking it.
They know things you do not, because they are the ones who will use it. Asking them before you build saves you building the wrong thing.
You Have Already Met This
In Systems Project 12 you designed something for a person who could not do a task. The rule there was ask, do not assume.
Same rule. The end user is the person you ask.
Do It — Plan It, Run It, Hand It Over
1. A goal for each role
Pick a challenge your team has not solved. Using your roles from Project 13, give every person one thing they are responsible for finishing.
| Role | Who | Their goal for this challenge |
|---|---|---|
| Driver | ||
| Navigator | ||
| Strategist | ||
| Builder |
2. Build the timeline
Break the challenge into steps. Put them in order, guess a time for each, and say who owns it.
| # | Step | Who | Minutes | Done by |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 4 | ||||
| 5 |
Add a Quarter Back On
Look at your Try It numbers. If your team guessed low every time, add a quarter to every estimate before you start.
That is not cheating. It is using evidence you collected ten minutes ago.
3. Run it, and watch the clock
Do the challenge. Tick each step off as it finishes and write down the real time.
| # | Planned | Actual | Why the difference |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 | |||
| 4 | |||
| 5 |
4. Look back at it together
| Question | Our answer |
|---|---|
| Did everyone meet their own goal? | |
| Did we finish inside our total time? | |
| Which step blew the timeline? | |
| Did that push anything else late? |
Somebody missed their step. How does your team say so without it turning into blame? Write the actual sentence you would use.
5. A job for somebody else
Now a real one. Your teacher gives your team a project with an end user who is not you. Option A A robot that puts recyclables into the right bin. Option B A robot that greets people by waving as they come into the classroom. Option C A robot that works as a quiz timer — starts driving and waving when time is up.
| Question | Our answer |
|---|---|
| We picked | |
| Who is the end user? | |
| What do they need it to do? | |
| How will we know it worked for them? |
6. Ask before you build
Go and ask your end user two questions before designing anything.
What we asked, and what they said:
7. Design it, time it, build it
Write a short timeline for this one and work through it.
| # | Step | Minutes | Who |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 | |||
| 4 |
8. Hand it over and be told what is wrong
Show it to your end user and your teacher. Ask one question: what did we not think of?
| Who | What they said | What we will change |
|---|---|---|
| Our end user | ||
| Our teacher | ||
| Another team |
Did anybody raise something your team had never considered? What was it?
⚠ You Do Not Have to Do Everything Suggested
Some feedback will not fit your , and some of it will be wrong. That is allowed.
What is not allowed is ignoring it silently. Say which suggestions you took, which you did not, and why.
9. Change it and show them again
Make the changes you decided on. Take it back to the same people.
What did you change, and were they satisfied?
Which suggestion did you decide not to take, and why?
Score It — Checkpoint
Better feedback
Rewrite each one so it is specific and about the work.
| Somebody says | Better version |
|---|---|
| “Your program is rubbish.” | |
| “It didn’t work.” | |
| “You always take too long.” | |
| “Yeah, it’s fine I guess.” |
Who is the end user?
| For this project, the end user is… | Who |
|---|---|
| A robot that sorts recycling in your classroom | |
| A quiz timer for your teacher’s lessons | |
| The claw you built in Project 7 |
Can you do it again?
Think about it
Your team guessed low in Try It and probably guessed low again on the timeline. Why does knowing about the problem not fix it?
A teammate tells you at the deadline that they have not started. What could your team have done differently a week earlier?
Your end user asked for something you think is a bad idea. What do you do?
Next
That is the Systems strand finished. You have taken a machine apart, designed for a real problem, built the arm your robot needed, worked out how machines talk, protected what is yours, and learnt to work with people.
Everything from here is the Coding strand — and every gate is now open.
Take your team goals from Project 13 back out and see how many you have met.
When you are finished, press the button to turn in your work and save a copy.
KIPR · Botball Explorer · Discovery