Next steps

• Comms: how are you going to communicate with each other during the week
• Git workflow: what does your git workflow look like?

User feedback

• Analyse feedback on your application as it is so far. Can users make use of any functionality
• If users cannot interact with your application - then this is also good feedback! How can you get feedback as quickly as possible?

If a guest speaker is available, they will join us for this session. We will ask them questions about their career and their work, and they will give us advice about their specialism.

This is a placeholder block.

We’re going to start off by defining rules and expectations for working on projects during this module.

📐 Ground rules

1. We go together
2. Do one project at a time
3. We will put in the time - 25 hours

🏗️ Projects

• We start a new project when everyone has finished the current one
• We can work as individuals or in groups
• “Done” means “Good enough to show an employer”
• 1 great user story is better than 10 meh user stories

🗣️ Communication

• Post a link to your deployed application by midnight at the end of every Thursday
• If everyone is ~done, we’ll start a new project on Saturday
• If you’re not done, LIST YOUR QUESTIONS AND BLOCKERS
• But don’t wait until Thursday to get help
• We are flexible to people’s needs: but you must express your needs

In addition to [who] and [what], good user stories also include [why]

As a [who], I can [what] so that [why]

Choosing a project

ℹ️ Use this section if you’ve not already chosen a project

Reflect and decide

Take 15 minutes (set a timer!) to share your progress and blockers with your team. This is a chance to ask for help and to help others. Don’t get into details - just share the headlines and arrange to talk more after the stand up if you need to.

🎯 1. Meet the criteria

• People We need at least two Launched trainees to start a module A minimum ratio of 1:4 volunteers to trainees
• Space A place to meet on Saturdays
• Time Volunteers and trainees must commit to 5 weeks of Saturday sessions
• Money The Docs will pay for trainee expenses like food, bus tickets, equipment and childcare
• A Plan Here’s the plan: it’s this module! When you have all these things, you can start a Portfolio module.

📅 2. Set the date!

• Choose a start date

As a team, you need to start thinking about and designing the user interface. To focus your discussion, keep these two things in mind for your UI:

Sufficiency

Sufficient means enough for a given purpose. Your user interface should provide enough functionality or data for users to achieve their goals.

Simplicity

Simple means easy to understand. Think of the number of times you’ve used a website and it’s been impossible to find the things you need. Your user interface should be simple and intuitive. Users should be able to figure how to navigate and use the user interface with minimal effort.

🖼️ Wireframe

🪞 Reflect and check

For your application to work, your user interface will interact with other services. These services provide data and ways to update this data via the user interface.

Here are the kinds of things these services may do:

📖 Reading

A means of reading data. The user interface might fetch data from some external source and render it in the interface.

💾 Persisting

A means of persisting changes. Users will need to create or update existing data. For example, a user might need to create a comment on an article. Another user may need to update the like/dislike on an existing comment. In each of these cases, any changes are persisted in a database. The user interface enables users to read and persist data without worrying about the

You’ll need to break up your user stories into manageable units of work. Breaking down tasks into sub-problems is challenging: we often don’t know in advance how challenging the sub-problem will be. However through iteration, practice and feedback we can continue improving how we break problems down.

🎟️ Issues

You can keep track of work using a GitHub project board as you’ve done throughout the course.

✅ Acceptance criteria

If you’re working on something, then you need a definition of “done”. In other words, you need to have measurable criteria for knowing when you’ve completed some task. Acceptance criteria are the requirements that must be met for a unit of work to be considered complete. Most often you’ll ue acceptance criteria to decide whether a user story has been implemented. Here are two ways of expressing acceptance criteria:

• Scenario-oriented (the Given/When/Then template)
• Rule-oriented (the checklist template) and

🫱 More detailed information on writing up acceptance criteria.

This time is set aside to work as a team on your project.

Use this time wisely

You will have project time every Saturday. Don’t waste it. Use it to:

• work through your backlog
• ask questions and get unblocked
• give and receive code review
• work on your portfolio

In this session we will work on our employability skills. This means: improving our CVs, LinkedIn profiles, GitHub profiles, finding and analysing job descriptions, and preparing for interviews.

This is a placeholder block.