Every CYF session begins with an energiser. Usually there’s a rota showing who will lead the energiser. We have some CYF 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.

Learning Objectives

Create a checklist that defines what’s needed for an increment to be releasable at the end of a Sprint

Preparation

Do the prep

Introduction

Many software projects have failed because they only found out at the end of the project that what they delivered was not valuable to the customers.

We should constantly validate what we are developing so that if we have misunderstood expectations, we can resolve them earlier. And we can realise the value we deliver sooner rather than waiting for a risky “big bang” deployment.

The Agile Manifesto highlighted the importance of working software over comprehensive documentation as the primary measure of progress.

The Scrum Guide (the leading interpretation of Agile) expects developers to agree on a Definition of Done, and to achieve “Done” for each item they work on in the backlog. This allows them to deliver an increment.

The product owner should focus on identifying and achieving “value”.

Definition of Done

🎯 Goal: Recognise the steps to achieve a “done” piece of software (30 minutes)

Work in small groups.

Make a list of acceptance criteria you would expect to be “done” for every software development user story (backlog item). You can refer to the links in the Prep.

Did you identify all the achievements necessary to deliver working software to a customer?
Did you add anything else which is not necessary?
Did you consider testing, automation, documentation, integration, coding style, acceptance, etc?

After you have a list, join another small group and share your ideas with them. What did you miss out?

Game: Anything but working software

🎯 Goal: Identify false alternatives to delivering valuable working software (30 minutes)

Work in small groups. Each person should take on one of the following roles at a time:

Lazy software developer
“Hacker” software developer
Bean-counter project manager
Salesperson
Proxy customer who is not the end user
Customer’s lawyer, who wants to verify the progress
Product Owner trying to maximise “value”.

You can have several people in the same role, and you can switch roles, so long as it’s clear what role you are playing at the time. Please caricature your role as a “Devil’s advocate”.

Go around your group, taking turns.

Propose something you could offer other than working software that is valuable or convenient for your role. For example, a video demo of the software. Or a specification of the product you are going to build.
Propose how this is “more valuable” than working software from your point of view.
The whole group should discuss if this is better or worse than delivering valuable working software. Sometimes the answer will be “yes”.

A quick break of fifteen minutes so we can all concentrate on the next piece of work.

Workshop Name

Replace this readme with the requirements for your workshop

Learning Objectives

Use the Teach Tech Together guide to construct your objectives
Limit the objectives to 3-5 items
Write objectives you can measure

Requirements

Explain the requirements of the workshop. You might want to talk about goals here. You might want to use formal specifications like Given/When/Then. It’s ok for requirements to be in different formats. We want trainees to learn to interpret requirements in many settings and expressions. Just make sure your workshop is active and not a lecture.

Always write your workshop in a readme.md in a folder with the same name as the workshop. This makes it easy to find and easy to show on the curriculum website.

Acceptance Criteria

I have provided clear success criteria
These might be related to the objectives and the requirements
I have given some simple, clear ways for trainees to evaluate their work
I have run Lighthouse and my Accessibility score is 100

Every Saturday at CYF we cook and 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 help with what is needed to make this happen, for example, organising the food, setting up the table, washing up, tidying up, etc. You can do something different every week. You don’t need to be constantly responsible for the same task.

What are we doing now?

You’re going to use this time to work through coursework. Your cohort will collectively self-organise to work through the coursework together in your own way. Sort yourselves into groups that work for you.

Use this time wisely

You will have study time in almost every class day. Don’t waste it. Use it to:

work through the coursework
ask questions and get unblocked
give and receive code review
work on your portfolio
develop your own projects

🛎️ Code waiting for review 🔗

Below are trainee coursework Pull Requests that need to be reviewed by volunteers.

LONDON_10 | Yulia - Hospodar | MODULE_DATABASES| Big Spender 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

Start a review

LONDON_10 | ANDRIUS_ISIN | MODULE_DATABASES| E-COMMERCE-API | WEEK 4 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

Start a review

London10_Jan_Softa_Module_Databases_Week1-4 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

Start a review

London 10 | Abubakar-Meigag | SQL WK 4 | E commerce api 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

Start a review

Glasgow Class 6 - Appolin Semegni Fotso - Module-Databases - E-Commerce-API - Week 4 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

Start a review

See more pull requests

Please feel comfortable and welcome to pray at this time if this is part of your religion.

If you are breastfeeding and would like a private space, please let us know.

What are we doing now?

You’re going to use this time to work through coursework. Your cohort will collectively self-organise to work through the coursework together in your own way. Sort yourselves into groups that work for you.

Use this time wisely

You will have study time in almost every class day. Don’t waste it. Use it to:

work through the coursework
ask questions and get unblocked
give and receive code review
work on your portfolio
develop your own projects

Retro (20 minutes)

A retro is a chance to reflect on this past sprint. You can do this on a Jamboard (make sure someone clicks “Make a copy” before you start, and you work on that together) or on sticky notes on a wall.

Set a timer for 5 minutes.
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.