You have already reviewed Sprint 2. Now use that review to set up your Sprint 3 work.

At the start of this sprint:

• • Look at your full project management board.

  • Find the cards labelled Sprint 3.

  • Move the Sprint 3 cards you are starting with into Ready / Next Up.

  • Add any new tasks from Sprint 2 testing or feedback.

  • Move any unfinished Sprint 2 tasks into Sprint 3 if they still need to be completed.

  • Check that your Sprint 3 tasks focus on final refinement, polish, testing, trialling, export, and readiness for delivery.

  • Make sure you have cards for development, testing, feedback, improvements, and final preparation tasks.

Your project management board is a live tool. You should update it as you work, not only screenshot it at the start.

Development evidence shows your progress, decisions, testing, and improvements.

You need to collect at least one clear piece of development evidence each week. This evidence should show what changed, what improved, and why — not just what the outcome looks like.

During Sprint 3, focus on refining your outcome so it becomes high quality, fit for purpose, and ready for final delivery. You should use evidence from Sprint 2 testing and feedback to guide your final development decisions.

Your Sprint 3 development might include:

• finalising content, assets, media, pages, screens, scenes, models, levels, layouts, or features

• fixing issues found during Sprint 2 testing and feedback

• improving visual design, composition, typography, colour, timing, movement, sound, or presentation

• improving usability, accessibility, navigation, readability, interaction, pacing, or flow

• refining more advanced tools, techniques, logic, effects, materials, animation, database features, or interactions where appropriate

• testing how individual components work

• testing how components work together

• trialling key parts of the outcome with others where useful

• making final improvements based on testing and feedback

• preparing the outcome for final export, publishing, rendering, build, manufacture files, presentation, or delivery

Evidence could include:

• screenshots of your working file, software, code, model, timeline, scene, layout, or project setup

• before and after comparisons

• short screen recordings or video captures

• exported previews, renders, builds, prototypes, test files, or mockups

• testing notes or checklists

• screenshots of errors, issues, fixes, or improvements

• feedback notes

• project management updates

• comments explaining what you developed, tested, changed, and why

You should be able to show that your outcome is becoming more complete, polished, usable, and fit for purpose.

Develop the final main version of your outcome.

Focus on refining the quality, usability, functionality, content, and overall user experience of your outcome. This is your last major development sprint, so your outcome should be very close to final by the end of this stage.

As you work, collect evidence each week.

For each piece of evidence, briefly explain:

• • what you refined, fixed, or improved

  • what testing or feedback influenced your decision

  • what changed from Sprint 2

  • what worked

  • what still needed fixing or polishing

  • what you changed or will change before final delivery

During development, think about:

• People - will users, viewers, players, clients, stakeholders, or experts understand and respond well to the outcome? 

• Components - which parts need final checking, refinement, or polish? 

• Connections - how well do the components work together? 

• Context - how, where, and why will the final outcome be used? 

• Interactions - how will users move through, control, view, read, listen to, or experience the outcome? 

• Quality - what needs to be refined so the outcome is clearer, more usable, more engaging, more polished, or more fit for purpose?

Evidence

In your document, include at least one clear piece of development evidence per week.

• This could be an image, screenshot, screen capture, short video, exported preview, render, prototype, test file, mockup, or testing note.

• Make sure your evidence is easy to understand. Add short comments or annotations explaining what changed, what improved, and why it matters.

Don't forget to move your Trello tasks as you go!

At the end of Sprint 3, you need to test the final main development version of your outcome.

Testing checks whether your outcome, or part of your outcome, works as intended. In Sprint 3, you are testing whether the outcome is now high quality, fit for purpose, and ready for final delivery.

This is not the final evaluation yet. It is about finding any last issues, checking that the outcome works well, and deciding what final touch ups or delivery tasks are still needed.

At this stage, you might test whether:

• the outcome can be opened, played, viewed, rendered, exported, published, presented, manufactured, or delivered

• the main structure, sequence, layout, scene, model, framework, or build works smoothly

• key components are complete and work together

• content, assets, media, visuals, audio, movement, interaction, or functionality are clear, polished, and appropriate

• navigation, controls, links, buttons, timing, pacing, readability, or flow work effectively

• files, assets, images, media, code, models, or database elements load correctly

• the outcome works in the intended software, browser, device, platform, format, or final context

• the outcome is usable, understandable, accessible, and suitable for final feedback

• any final errors, weak areas, unfinished parts, or technical issues need to be fixed before launch/delivery

Evidence to include

• screenshots or video of the working Sprint 3 version

• exported preview, render, build, prototype, published link, test file, or manufacturing/export file where relevant

• a short final testing checklist

• notes on what has improved since Sprint 2

• notes on what is working well

• notes on what still needs final touch ups

• issues that need to be addressed before launch/delivery

Testing is different from feedback. Testing checks whether the outcome works. Feedback helps you understand whether the outcome works well for people, purpose, and context. 

Export, preview, publish, render, build, present, manufacture-preview, or share your current Sprint 3 version so it can be tested.

Create a short testing checklist that focuses on whether your outcome is high quality, fit for purpose, and ready for final delivery.

Your checklist should help you answer:

• What has improved since Sprint 2?

• What parts of my outcome are working well?

• What parts still need final checking?

• What errors, issues, or weak areas did I find?

• What final touch ups are needed?

• What needs to happen before launch/delivery?

In your document, include:

• evidence of the version you tested

• your testing checklist or notes

• a short summary of what the testing showed

• any final issues or touch ups that need to be added to your project management board 

Testing checks whether your outcome works. Trialling checks whether your outcome works well for people.

At the end of Sprint 3, share your near-final version with at least one suitable person. This could be an end user, client, stakeholder, teacher, technical expert, or peer who matches your intended audience.

At this stage, your outcome should be close to final. You are trialling the quality, usability, functionality, presentation, and fitness for purpose of your outcome so you can decide what final touch-ups are needed before launch/delivery.

Trialling helps you find out:

• • whether the purpose of your outcome is clear

  • whether the outcome is suitable for the intended users

  • whether users can understand, view, use, play, navigate, read, listen to, or interact with it as expected

  • whether the content, features, assets, style, or technical choices are effective

  • whether the outcome feels polished and appropriate

  • whether anything still needs fixing, adjusting, or clarifying

  • whether the outcome meets end-user requirements

  • what final touch-ups are needed before launch/delivery

Share your Sprint 3 version with at least one suitable person.

This could be:

• an end user

• a client or stakeholder

• a teacher

• a technical expert

• a peer who matches your intended audience

Ask them to trial your outcome and give feedback on its quality, usability, functionality, presentation, and fitness for purpose.

In your document, include:

• • who gave feedback and their role

  • what version or component they trialled

  • the questions you asked

  • what feedback they gave

  • what you will change because of the feedback

  • what feedback you will not use, if relevant, and why

Finish this section with:

• From the feedback I have received, I will complete the final touch-ups …

• Then explain the changes, fixes, or improvements you will make before launch/delivery.

At the end of Sprint 3, review your evidence and update your project management board.

This review should show where your project has ended up after the main development sprints and what final touch ups, tweaks, or delivery tasks are still needed.

Your project board should now show:

• • tasks that were completed during Sprint 3

  • tasks that are still in progress

  • tasks that were tested or reviewed

  • tasks that need final fixing, improving, or polishing

  • any new tasks added because of final testing or feedback

  • any tasks that need to move into the Launch/Delivery/Evaluation stage

  • any tasks that are no longer needed or are no longer realistic

This does not need to be long. The goal is to show what still needs to happen before your final outcome is delivered, presented, placed in context, or evaluated.

Update your project management board at the end of Sprint 3.

Move your cards into the correct columns, such as:

• Done — tasks completed during Sprint 3

• Testing / Review — tasks/components that still need checking

• Fix / Improve — tasks that need final changes after testing or feedback

• Ready / Next Up — final touch ups or delivery tasks that need to happen next

Take a screenshot of your updated board and add it to your document.

Under the screenshot, write a short review using the prompts below.

Sprint 3 review prompts

• What Sprint 3 tasks did I complete?

• What did I not complete, and why?

• What testing or feedback affected my final decisions?

• What final touch ups, tweaks, or fixes are still needed?

• What tasks need to move into the Launch/Delivery/Evaluation stage?

• Have any tasks changed priority?

• Are there any tasks I am removing or no longer completing? Why?

• What final changes will help my outcome become high quality and fit for purpose?

Keep it brief

You only need a short paragraph or a few bullet points.

For example:

I completed the final layout refinements, fixed the main usability issues, and improved the visual consistency. I did not complete the extra animation because final testing showed the instructions and mobile layout were more important. I have moved final spelling checks, export settings, and in-situ screenshots into the Launch/Delivery stage.

Before moving into Launch/Delivery/Evaluation, save a clear backup of your Sprint 3 work. 

What to do

• Save or export the current Sprint 3 version of your outcome.

• Create a backup copy of your project folder.

• Rename the backup clearly, for example:
  ProjectName_EndOfS3
  StudentName_Project_EndOfSprint3
  Game_EndOfS3_WorkingVersion

• Store the backup in the correct folder or backup location.

• Check that your working files, assets, exports, evidence, and feedback are included. 

• Keep this version safe before making final touch ups or delivery changes.