During sprint planning, you'll estimate all of the issues in your backlog. Once everything has been estimated, you'll be ready to plan what you'll work on in the next sprint.
Before the sprint begins, set up a project board with all of the user stories you'll work on. You'll be able to refer to this to track your progress throughout the sprint.
During the Tech for Better projects, your Product Owner will join your planning sessions. The Product Team should lead the process and give the Product Owner a clear idea of what you'll be working on in the next sprint.
In a sprint review, the Scrum Facilitator will lead the team in working out the actual complexity of each issue tackled. Add actuals as labels to the issues you completed within the sprint and use these to calculate your velocity for the sprint.
After completing a review of your first sprint, you'll be able to better manage your next sprint backlog with your velocity in mind.
Towards the end of your cohort, you'll have the opportunity to reflect with the rest of your cohort on the mentoring you've received. The goal of this reflection is to come up with ideas for what you'd like to take forward to mentoring the next cohort.
You'll have 75 minutes to reflect and share your thoughts together.
Spend the first 10 minutes thinking individually and writing a list of things you found were good qualities, or behaviours which you saw from your mentors.
You'll then split into small groups to come up with a shared list, building on your individual reflections.
After 15 minutes in your small groups, we'll come back as a cohort. Each group will take turns to share each reflection from their list.
Someone in the cohort can be nominated to take notes and add the document somewhere for you all to refer back to.
At the end of the session, we'll ask you to fill in an airtable form with your preferences on which week you'd like to mentor for the next cohort.
When you're mentoring the next cohort, you can refer back to your reflections to guide your mentoring.
At the end of your Tech for Better project, you'll hand the project over to your Product Owner. For a smooth transition, you'll write documentation to help them continue to manage the product.
Start by showing them around the application and what features you've built. It's important that they understand how it works, and that you will no longer be able to contribute to the repository.
If you do find bugs, don't aim to fix them in the handover. Open issues which give details of the bugs, and how they might be fixed. This will allow your PO to pick up development further down the line.
Share the repository with your PO. You can add them, if they want to make a profile, or just share the link. Make sure you have a clear README with details of the stack, and how the project fits together.
Show them the Product Backlog and let them know what is still to be included. They'll manage this backlog if they continue to develop the product.
Pass any logins to your Product Owner and make sure they can manage the deployment, and any CMS you've built moving forward. Do not share your personal login to the platform, encourage them to create their own and transfer ownership.
If your Product Owner mentions continuing work on the Product, you can direct them to chat to the team at Founders and Coders. We can support them with finding developers to work on the project. You may also like to show them how to create issues on GitHub, if they are planning further features to develop.
The presentations for Tech for Better are a little different from the other ones you've delivered during the programme. We'll host a showcase of projects on the last day of term. We invite alumni, and other friends and family along to watch the presentations.
You will present for a maximum of 15 minutes, alongside your Product Owner.
Your audience won't all be technical experts, and you'll want to include the right level of detail for everyone. Talk about some of the challenges of building the product, and try to keep these high-level.
You may get some questions from the audience, who'd like to learn more about what you've been working on. If there's a question you'd like to be asked, you can ask another member of your cohort to ask it 😉
Introduce yourselves and your Product Owner to the audience. Include your project role in your introduction.
It can be a nice touch to take turns introducing another member of the team; and paying them a compliment on their work.
Detail what problem the Product Owner wanted to solve. You might like to ask your Product Owner to talk through this slide, and include a Problem Statement.
Talk about how you planned and designed the Product with your PO. Include screenshots of your design process.
Give details on the stack you chose, and why you chose each technology.
Talk through the main features of the product, and show the user journey. We encourage you to pre-record a demo, and include a video in your slide deck. This can help to avoid any unexpected issues on the day, and can help keep the demo well-timed.
Talk about some of the challenges you faced during the build. This might be related specifically to your role, and you might like to follow this structure:
What the challenge was
How you solved it
The benefit of solving that challenge
Let the audience know about your big achievements in this build. What did you do that you were proud of?
What did you learn during the project? Give your PO time to talk about what they learnt throughout the programme too.
Give your Product Owner time to talk about the direction of the product and where they'll take it next. They might be looking for further funding or development, or testing the MVP with their user group.
Share the speaking time evenly throughout your team. Each person, including the Product Owner, should aim to speak for 2 - 2.5 minutes.
The structure here is an outline, and you can adapt it to make the presentation your own.
We recommend using Canva for your slide deck ✨
There are two kinds of user feedback sessions in the design sprint: User Research, and Usability Testing.
User research gives us an opportunity to validate whether we’re on the right track, or if we’re designing something that wouldn’t address user needs.
When conducting user research it’s important to keep an open mind and to be unafraid of readdressing our approach.
Critical feedback is incredibly useful to us so we want to encourage our users to be open and honest.
You'll be asking the participant questions from a script prepared ahead of time, and taking notes of their answers.
It is important that you help the user feel comfortable and ask open questions as well as giving the user space to share their own thoughts.
Users might not have participated in research before so there often is a tendency to tell us what we’re expecting to hear. But critical feedback is incredibly useful to us so we want to encourage our users to be open and honest.
Wherever possible, we want to avoid including our own biases in questions and conversations as part of user research.
Always be mindful of the participants right to privacy.
Once the interviews are all conducted you will synthesise the feedback in your project groups during the Analysis workshop.
Usability testing is a process for getting feedback from real people in order to inform the decisions we make on designing and building a digital product.
'User Testing' and 'Usability Testing' refer to the same thing. The phrase ‘usability’ encourages us to remember it is not the user who we’re testing but the usability of our app or product. Do take the opportunity to rethink your app, and take all criticism constructively!
You will be conducting an interview where you will ask the user to navigate through your Figma prototype.
Keep your explanation brief. Introduce them to the project idea in one or two sentences and explain how usability testing works.
Giving them a few tasks to complete and observing how they interact with the prototype will give you an idea of how intuitive it is to interact with the product you're creating.
Feedback from testing will help inform your decisions on which features to prioritise when building.
During the In-House project design sprint (week 7) you will be conducting both user research and usability testing.
The Tech for Better Product Owners will conduct their own user research, but you will be conducting a usability testing session with their user group.
Check the design week schedules for exact timings:
For the In-House project, you will need 1-2 volunteers per person to participate:
User research (1-2 volunteers each, 6 per team)
Usability testing (1-2 volunteers each, 6 per team)
Each research session will last 90 minutes, whereby each interview will take around 20-30 minutes to conduct.
They will be 2-1 interviews over zoom (2 developers interview one participant) , or face to face wherever possible.
You will conduct the research in pairs, where one person will be taking the lead and asking questions, whereas the other person will be taking notes on the volunteers answers.
Please swap roles between interviews so that everyone gets a chance to ask questions.