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

At the start of this sprint:

• Look at your full project management board.

• Find the cards labelled Sprint 2.

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

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

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

• Check that your Sprint 2 tasks focus on improving quality, content, functionality, user experience, and fitness for purpose.

• Make sure you have cards for development, testing, feedback, and improvement 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 2, focus on developing your outcome into a more complete and refined version. You should use evidence from Sprint 1 testing and feedback to guide your decisions.

Your Sprint 2 development might include:

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

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

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

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

• fixing issues found during Sprint 1 testing and feedback

• testing how individual components work

• testing how components work together

• trialling key parts of the outcome with others where useful

• making improvements based on testing and feedback

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, usable, and fit for purpose.

Develop the next version of your outcome.

Focus on improving the quality, usability, functionality, content, and overall user experience of your outcome. It should be more complete than Sprint 1 and developed enough for meaningful testing or feedback.

As you work, collect evidence each week.

For each piece of evidence, briefly explain:

• what you developed or improved

• what testing or feedback influenced your decision

• what changed from Sprint 1

• what worked

• what needed fixing or improving

• what you changed or will change next

During development, think about:

• People - who will use, view, interact with, or give feedback on your outcome?

• Components - which parts need to work well on their own?

• Connections - how do the components work together?

• Context - where, how, and why will the 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, or more polished?

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 2, you need to test the more complete version of your outcome.

Testing checks whether your outcome, or part of your outcome, works as intended. In Sprint 2, you are testing whether the main components work together and whether the outcome is becoming more complete, usable, and fit for purpose.

This is not about proving that your outcome is finished. It is about finding out what has improved since Sprint 1, what still needs refining, and what needs to be fixed before Sprint 3.

At this stage, you might test whether:

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

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

• key components are included and work together

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

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

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

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

• the outcome is usable, understandable, and suitable for more meaningful feedback

• any errors, weak areas, unfinished parts, or technical issues need to be fixed before Sprint 3

Evidence to include

• screenshots or video of the working Sprint 2 version

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

• a short testing checklist

• notes on what has improved since Sprint 1

• notes on what is working well

• notes on what still needs fixing or refining

• issues that need to be addressed in Sprint 3

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, or share your current Sprint 2 version so it can be tested.

Create a short testing checklist that focuses on whether your outcome is becoming more complete, usable, and fit for purpose.

Your checklist should help you answer:

• What has improved since Sprint 1?

• What parts of my outcome are working well?

• What parts are not working yet?

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

• What still needs to be refined or polished?

• What should move into Sprint 3?

In your document, include:

• evidence of the version you tested

• your testing checklist or notes

• a short summary of what the testing showed

• any issues or improvements 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 2, share your more complete 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 developed enough for more meaningful feedback. You are trialling the usability, quality, content, functionality, and overall direction of your outcome so you can decide what needs final refinement in Sprint 3.

Trialling helps you find out:

• whether the purpose of your outcome is clear

• whether the outcome is becoming 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 anything is confusing, unfinished, missing, or not working well

• whether the outcome is meeting end-user requirements

• what should be refined, fixed, or polished in Sprint 3

Share your Sprint 2 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 the usability, quality, content, functionality, and overall direction of your outcome.

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 develop…

  • Then explain the changes, fixes, or improvements you will take into Sprint 3.

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

This review should show where your project is up to and what decisions you need to make before starting Sprint 3.

Your project board should now show:

• tasks that were completed during Sprint 2

• tasks that are still in progress

• tasks that were tested or reviewed

• tasks that need fixing, improving, or polishing

• any new tasks added because of testing or feedback

• any tasks that need to move into Sprint 3

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

This does not need to be long. The goal is to show how Sprint 2 has affected your plan for Sprint 3.

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

Move your cards into the correct columns, such as:

• Done - tasks completed during Sprint 1

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

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

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 2 review prompts

• What Sprint 2 tasks did I complete?

• What did I not complete, and why?

• What testing or feedback affected my next steps?

• What tasks need to be fixed, improved, polished, or continued in Sprint 3?

• Have any tasks changed priority?

• Are there any tasks I am moving to later, removing, or adding? Why?

• What final refinements will help my outcome become high quality?

Keep it brief

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

For example:

I completed the main content, improved the layout, and added the key interaction. I did not finish the final animation because user feedback showed that the navigation needed to be clearer first. I have moved the animation polish into Sprint 3 and added a task to improve the instructions before final testing. 

Before moving into Sprint 3, save a clear backup of your Sprint 2 work.

This helps protect your progress and gives you a version you can return to if something breaks later.

What to do

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

• Create a backup copy of your project folder.

• Rename the backup clearly, for example:
  ProjectName_EndOfS2
  StudentName_Project_EndOfSprint2
  Game_EndOfS2_WorkingVersion

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

• Check that important files, assets, links, media, database files, exports, or working files are included.

• Make sure your evidence screenshots/videos are also saved in the right place.

Before you move on

Back up your Sprint 2 version and file it clearly as End of S2. This creates a safe checkpoint before you begin making Sprint 3 changes.