Learning Goal

You write a Learning Goal twice in the Learning Group: once for Sprint 1-2 and once for Sprint 3-4. Each Learning Goal describes what you want to learn in that period, how you plan to work toward it, and how you will show that you learned it.

You structure the Learning Goal with the STARRT method: Situation, Task, Action, Result, Reflection, and Transfer. You grow the same Portflow evidence over the period:

When	STARRT steps	What you write
Start of Sprint 1-2 / 3-4	Situation, Task, Action	Context, what you set out to learn, and your plan of tasks
During the period	Result	Evidence and what each result shows
End of the period	Reflection, Transfer	What it means, and what you will do next

Learning Goal in Portflow

Each Learning Goal belongs to your Personal Leadership Learning Outcome. Place it in Portflow in the collection Learning Group, as Free-Text evidence.

Use this title format:

1	`Sprint [1-2 or 3-4] - Learning Goal - [City Challenge]`

For example: Sprint 1-2 - Learning Goal - Smart Traffic Light System

Start — Situation, Task, Action (STA)

Create the Learning Goal at the start of Sprint 1-2 or Sprint 3-4. Fill in Situation, Task, and Action.

Before you write, answer these questions for yourself:

Situation: Which period is this (Sprint 1-2 or 3-4), which city challenge are you on, and what situation are you in?
Task: What do you want to get better at in this period, and why does that matter for the city challenge? What is your learning question? How will you know it worked?
Action: What concrete tasks will you work on to answer that learning question? In which order will you do them? (This is your plan — not a list of finished products.)

Copy-paste this into Portflow and replace the brackets:

Situation:

Sprint [1-2 or 3-4] — [City Challenge]. [Describe the situation you are in and the problem or opportunity for the city.]

Task:

In Sprint [1-2 or 3-4] I want to learn [skill / knowledge / approach], because [why this matters for the challenge].

Learning question: [One question you will try to answer in this period.]

How I will know it worked: By the end of Sprint [1-2 or 3-4] I can show that [observable result: e.g. a working demo, a clear advice, a justified design choice].

Action:

My plan for this period:

[Task 1 — what you will work on first, and roughly when]
[Task 2 — next step that builds on task 1]
[Task 3 — …]
[Task 4 — …]

Keep the list short and concrete (about 4–6 tasks). Focus on the work you will do, not on product titles.

During — Result (R)

When you finish a product or other piece of evidence, add it in Portflow and link it from your Learning Goal. Append this Result block and repeat the list items as needed:

Result:

@Link-to-evidence-in-Portflow — [One sentence: what this evidence shows]
@Link-to-evidence-in-Portflow — [One sentence: what this evidence shows]
@Link-to-evidence-in-Portflow — [One sentence: what this evidence shows]

(Just append this at the end of your Learning Goal.)

End — Reflection and Transfer (RT)

At the end of Sprint 1-2 or Sprint 3-4, append Reflection and Transfer to finalize the Learning Goal.

Use these questions:

Reflection: What went as planned, and what turned out differently? Did you follow your Action plan, or did you change it? What do your results say about your learning question and about how you work in practice?
Transfer: What concrete change will you apply in the Group Project or in a future Learning Goal?

Reflection:

[What went well and what was harder than expected. Whether your Action plan held or changed. What your results mean for your learning question and for how you work in practice.]

Transfer:

[One concrete change you will apply in your Group Project or in a future Learning Goal.]

(Just append this at the end.)

Example

Below is a filled STARRT example for the Smart Traffic Light System challenge. Use it as a model, not as text to copy unchanged.

Title: Sprint 1-2 - Learning Goal - Smart Traffic Light System

Situation:

Sprint 1-2 — Smart Traffic Light System. Our Learning Group city needs a prototype that detects a car at the approach and switches the traffic light so traffic can move safely.

Task:

In Sprint 1-2 I want to learn how to connect a vehicle sensor to an ESP32 and control lights with clear timing rules, because the city challenge depends on reliable detection and a predictable light response.

Learning question: Which vehicle-detection sensor and timing rules best fit our lane prototype, given range, false triggers, and wiring constraints?

How I will know it worked: By the end of Sprint 1-2 I can show a demo where no car keeps the light red, and a detected car updates the light to green according to our rules.

Action:

My plan for this period:

Week 1 — Compare ultrasonic and IR options (range, false triggers, wiring) and pick a sensor for the lane prototype.
Week 1–2 — Draft detection rules and light timing (when red stays, when green starts, fail-safe behaviour).
Week 2 — Draw the pin map and a simple state diagram for sensor → light behaviour.
Week 2–3 — Wire the sensor and LEDs on the bench and write firmware for detect → update light.
Week 3–4 — Test false triggers, adjust timing rules, and prepare a short demo with validation notes.

Result:

@Research-advisory-report — Compares ultrasonic vs IR and recommends detection rules for our lane
@Embedded-design — Pin map and state diagram for sensor → light behaviour
@Traffic-light-demo — Bench demo: car present → green; no car → red

Reflection:

I followed the plan for research and wiring, but false triggers forced an extra loop on timing rules in week 3. That answered the learning question: range alone is not enough — timing rules matter as much as the sensor choice.

Transfer:

In the Group Project I will write detection rules and a simple test script before wiring the full circuit, so we catch false triggers earlier.