Register
Energiser
Every session begins with an energiser. Usually there’s a rota showing who will lead the energiser. We have some favourite games you can play if you are stuck.
- Traffic Jam: re-order the cars to unblock yourself
- Telephone: draw the words and write the pictures
- Popcorn show and tell: popcorn around the room and show one nearby object or something in your pocket or bag and explain what it means to you.
Morning orientation
Learning Objectives
Planning during the week
π£ Steps
If you haven’t done so already, choose someone (volunteer or trainee) to be the facilitator for this morning orientation block. Choose another to be the timekeeper.
ποΈ The Facilitator will:
- Assemble the entire group (all volunteers & all trainees) in a circle
- Briefly welcome everyone with an announcement, like this:
π¬ “Morning everyone, Welcome to CYF {REGION}, this week we are working on {MODULE} {SPRINT} and we’re currently working on {SUMMARISE THE TOPICS OF THE WEEK}”
- Ask any newcomers to introduce themselves to the group, and welcome them.
- Now check: is it the start of a new module? Is it sprint 1? If so, read out the success criteria for the new module.
- Next go through the morning day plan only (typically on the curriculum website) - and check the following things:
Facilitator Checklist
- Check the number of volunteers you have for the morning
- Check someone is leading each session
- Describe how any new activities works for the group
- Decide how best to allocate trainees and volunteers for a given block - most blocks will make this clear
β° The Timekeeper will:
- Announce the start of an activity and how long it will take (check everyone is listening)
- Manage any whole class timers that are used in an activity
- Give people a 10-minute wrap-up warning before the end of an activity
- Announce the end of an activity and what happens next
Demo Questions & Answers
Learning Objectives
Professional Q&A Experience Workshop
In ITP you have practised giving demos - short presentations to get practice speaking in a professional setting. Later on, during an interview, presentation, or other work discussion, you will also be expected to ask and answer questions. The goal of this workshop is to give you practice in asking meaningful questions and giving good answers.
Plan
To get the best out of this workshop, please use a short demo on a topic you are comfortable discussing. The goal here is not the quality of the demo. It is to practice questions and answers, so you can re-use a demo you have previously given.
There are 2 criteria we want to meet:
- Every listener should ask at least 1 question during this workshop
- Every presenter should answer at least 1 question during this workshop
Take a moment to read through the tips below before you begin. Feel free to refer to these tips during the Q&A if that would help.
To ensure everyone has a chance to take part, get into groups of at most 5 trainees (and ideally at least one volunteer).
Take turns:
- Each demo should be no more than 5 minutes long
- Give up to 3 minutes for questions and answers
- Try to keep questions short, take up to 1 minute to answer
After everyone has had a chance to practice asking and answering, have a discussion as a group about the process:
- How did you find asking and answering: Was there anything easy or difficult about it?
- Give each other feedback on their Q&As: Did any good examples stand out, could any have been improved?
- What would you do differently if you were in a similar Q&A situation in the future? The feedback and discussion for this workshop should focus on the questions and answers, not the content of the demos.
Tips for Asking Good Questions
- This is different to the kind of rhetorical question you might have used when doing a demo
- Unless the speaker made it clear they want you to, don’t interrupt them mid-demo
- If the speaker says something you would like to know more about, you can remember it and ask at the end
- If the speaker said something unclear, or that you disagree with, you can ask politely about it at the end
- A good question is short and to the point. Remember: as the audience you’re not the main focus
Example Questions
The best questions to ask come from ideas the demo made you curious about. If you can’t think of any, you can use or adapt one of these, if they’re appropriate:
- If you were to do it again, what would you do differently?
- What did you enjoy the most about this?
- What was your biggest challenge?
- How does this compare to (some other way of doing something similar)?
- Could you explain how (this idea) could be used or adapted for (some related setting or project)?
- When I tried something similar, I encountered (this problem), how did you overcome that?
Tips for Giving Good Answers
- Know that you will never be able to prepare for every possible question.
- Listen carefully to what is being asked - you don’t want to answer the wrong thing.
- If you did not understand the question, you can ask them to reword it.
- Take a moment to think about your answer before you start to speak.
- Repeating the question back in your own words gives you time to start forming an answer, and it confirms to the asker that you understood what they were asking.
- If you can’t think of a good answer, it is fine to say you don’t know. This is better than giving an unclear long-winded reply.
Extra resources
Review
Look back over the objectives of this activity - check you've met them all. If you haven't, make sure you have a plan for how to achieve them - maybe checking in with a volunteer or a fellow trainee could help?Teamwork Project Sprint 2
Learning Objectives
ππ½ PD Session: Teamwork Project Sprint 2
β±οΈ Time: 15 minutes
Prep
Post-its and pens for each team
A collaborative board (physical or digital) for each team
Ensure trainees have completed the required reading on Product/MVP concepts
Introduction
Before any code is written, product managers and business analysts work with stakeholders to understand what to build and why. They ask: Who are our users? What do they need? What is the smallest useful thing we can ship?
In this session we explore that process β moving from a product idea to a clear understanding of users, needs, and priorities.
β±οΈ Time: 20 minutes
π― Goal: Define and differentiate Product, MVP, Feature, and User Story
Instructions
Create a collaborative board with four columns: Product, MVP, Feature, and User Story.
Class Discussion: Briefly define each concept as a group.
Post-it Activity: Each trainee writes one phrase or word per Post-it (e.g., “The smallest version of a product that allows a team to collect the maximum amount of validated learning” for MVP) and places it in the correct column.
Review the board as a group to clarify any misconceptions.
β±οΈ Time: 20 minutes
π― Goal: Identify target audiences and their specific needs
Instructions
Let’s assume we are building a job board for people looking for their first role in tech.
Discuss the following as a team:
- Who are your users? (e.g., first-time jobseekers, experienced recruiters, hiring managers at small startups)
- What different user profiles exist? (e.g., a “Guest browsing jobs” vs. a “Registered jobseeker” vs. an “Employer posting a role”)
- What specific needs does each user have? How might those needs conflict?
- Which users matter most for your MVP?
Deliverable: Write a short description of the product, its users, and their needs. Choose a spokesperson (ideally someone new) to present this to the class in 1 minute.
β 15 minute break
β±οΈ Time: 20 minutes
π― Goal: Connect product features to user needs, and practise prioritisation
Instructions
Internal Brainstorm: In your teams, answer:
- What is the primary functionality of your product?
- How exactly does it solve the needs identified in Exercise 2?
- If you could only ship three features for your MVP, which would you choose and why?
Peer Review: Pair up with another team.
Feedback Loop: Share your answers with the other team. Provide constructive feedback on their prioritisation choices β do you agree with what they included in the MVP? What did they leave out that you would have included?
β±οΈ Time: 15 minutes
π― Goal: Connect today’s exercises to real product and BA practice
Talk with your volunteers about how this works day-to-day:
- Who decides what gets built β product managers, engineers, stakeholders, or all three?
- How do teams find out what users actually need? (user research, interviews, analytics)
- How do you decide what goes in the MVP vs what comes later?
- What happens when different stakeholders disagree on priorities?
This is a chance to ask questions and hear real examples from people working in tech today.
Review
Look back over the objectives of this activity - check you've met them all. If you haven't, make sure you have a plan for how to achieve them - maybe checking in with a volunteer or a fellow trainee could help?Community Lunch
Every Saturday, we eat together. We share our food and our stories. We learn about each other and the world. We build community.
This is everyone’s responsibility, so let’s work together. These are the roles we need help with.
- Food shopping: ensure enough food is available for all courses running in your region, respecting the dietary requirements and the budget (you might not be the one buying the food, but you should ensure whoever buys or cooks the food knows what should be bought)
- Setting up the table: organise the food so that everyone has access to it and invite people to join lunch
- Washing up & tidying: your location should be as clean as it was before you all arrived in the morning. This can include washing up, taking the litter outside, hoovering, etc.
You can do something different every week or every two weeks. You shouldn’t have to be constantly responsible for the same task. Agree as a cohort on how you will manage this.
Questions you can use to help this organisation:
- How long should each person (group of people) be responsible for each goal? 1 week? 2 weeks?
- How will we communicate to our community who is the person responsible right now?
- Is there any role missing?
Study Group
Learning Objectives
Trainees
This is time for you to get help with whatever you need help with.
If you didn’t understand something in the prep, ask about it.
If you were struggling with a backlog exercise, get help with it.
If you weren’t quite sure of something in a workshop, discuss it.
If you don’t have any problems, keep working through the backlog until you need help.
It can be useful to get into groups with others facing the same problem, or working on the same backlog item.
Volunteers
Don’t be scared to approach people and ask what they’re working on - see if you can help them out, or stretch their understanding.
If lots of people have the same problems, maybe you can put together a demonstration or a workshop to help them understand.
If absolutely no one needs help, consider reviewing some PRs using the process and guidelines in the #cyf-code-review-volunteer-team Slack channel canvas.
Breaks
No one can work solidly forever! Make sure to take breaks when you need.
Finished everything?
If you have finished everything in the backlog you can use this time to practice some other skills which will be useful in your future careers. We have some suggestions below:
Pair programming
Pair programming is very common in industry so it’s good to practice it now! Find a partner and choose a problem to work on, for example a Codewars kata. One person will be the “driver” and the other will be the “navigator”. Both of you will use the same laptop to complete the activity.
- The “driver” is the person typing on the keyboard, just thinking about what needs to be written
- The “navigator” reviews what the driver is doing and is thinking about to write next
- Switch between driver and navigator roles after
- Don’t dominate - this is teamwork
There are further details in our Pair Programming Guide.
Code review
You will receive regular reviews of your work from volunteers when you submit a PR, but how comfortable are you giving a review? Find a partner and give each other feedback on one of the PRs you submitted this week. After you have given your feedback you should consider:
- How did you understand what the goal of the PR is? Did you read the title and description, look at the coursework exercises, etc.
- How did you use the different tabs in the PR:
Conversation,Commits,Files changed. - What made a PR easy or hard to review:
- Where unrelated files/lines changed?
- Was code consistently formatted? Did indentation help or hurt understanding?
- How did you review the code? Did you read top-to-bottom? Did you jump around into and out-of functions? Did you look at tests? Did you clone the code locally and try running it?
Prepare for your next demo
You need to give regular demos to complete the course. Use this time to work on your next one. You could:
- Prepare your slides
- Discuss topics
- Practice presenting
Share resources you have found
CYF aren’t the only resource available to you! If you have discovered a new book, YouTube channel or anything else you are using to help you learn this is an excellent time to share it with your cohort.
Retro: Start / Stop / Continue
πΉοΈRetro (20 minutes)
A retro is a chance to reflect. You can do this on RetroTool (create a free anonymous retro and share the link with the class) or on sticky notes on a wall.
- Set a timer for 5 minutes. There’s one on the RetroTool too.
- Write down as many things as you can think of that you’d like to start, stop, and continue doing next sprint.
- Write one point per note and keep it short.
- When the timer goes off, one person should set a timer for 1 minute and group the notes into themes.
- Next, set a timer for 2 minutes and all vote on the most important themes by adding a dot or a +1 to the note.
- Finally, set a timer for 8 minutes and all discuss the top three themes.