L1 3D Modelling
~+~ Development Sprint 1 ~+~

Set up your project files before you continue developing your outcome.

Create a clear folder structure for your project. Depending on your outcome, this could include folders for:

• • working files

  • images, media, models, or assets

  • code, scripts, styles, or project files

  • exported or published versions

  • screenshots and evidence

  • testing and feedback

  • backup or old versions

Use clear file and folder names so you can tell what each file is and which version it belongs to.

You should also set up a backup system. This might be:

• Google Drive

• OneDrive

• GitHub

• school network drive

• external drive

• another folder for backup copies

Before making major changes, save a new version or make a backup copy so you can return to an earlier working version if something breaks.

In your document, add screenshots or notes showing how your project files, exports, evidence, and backups are organised.

Development evidence shows your progress, testing, and improvements.

You need to collect at least one clear piece of development evidence each week. This evidence should show what you developed, what you tested, what changed, and what still needs to be improved.

During Sprint 1, focus on creating the core structure and basic functionality of your outcome. This is the first working version, so it may still include placeholder content, rough assets, draft layouts, or unfinished visual details.

Your Sprint 1 development might include:

• setting up the main structure, layout, sequence, scene, model, or framework

• creating key components, pages, screens, scenes, sections, models, or assets

• adding placeholder or draft content

• building basic interaction, navigation, movement, timing, or functionality

• setting up technical elements such as canvas size, timeline, database structure, export settings, engine scenes, CAD components, or document setup

• testing individual components to check they work as expected

• testing how different components work together

• making changes based on what you discover during testing

Evidence could include:

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

  • before-and-after screenshots

  • short screen recordings or video captures

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

  • testing notes or checklists

  • screenshots of errors, issues, fixes, or improvements

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

Develop the first working version of your outcome.

Focus on the core components that will get your outcome set up and functioning. It does not need to be polished yet, but it should be developed enough to test.

As you work, collect evidence each week.

For each piece of evidence, briefly explain:

• what you developed

• what you tested

• 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 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?

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, or testing note.

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

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

At the end of Sprint 1, you need to test the first working version of your outcome.

Testing checks whether your outcome, or part of your outcome, works as intended. In Sprint 1, you are mainly testing the core structure and basic functionality.

This is not about proving that your outcome is finished. It is about finding out what is working, what is not working yet, and what needs to be fixed or improved before Sprint 2.

At this stage, you might test whether:

• • the first version can be opened, played, viewed, rendered, exported, built, or presented

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

  • key components are included and easy to understand

  • basic navigation, interaction, movement, timing, links, buttons, controls, or functionality work

  • 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 readable, viewable, usable, or understandable enough for early feedback

  • any major errors, missing parts, or technical issues need to be fixed

Evidence to include

• screenshots or video of the working Sprint 1 version

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

• a short testing checklist

• notes on what worked

• notes on what did not work yet

• issues that need to be fixed in Sprint 2

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

Create a short testing checklist that focuses on your core structure and basic functionality.

Your checklist should help you answer:

• What parts of my outcome are working?

• What parts are not working yet?

• What errors or issues did I find?

• What needs to be fixed or improved next?

• What should move into Sprint 2?

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 makes sense for people.

At the end of Sprint 1, share your first working version with at least one suitable person. This could be an end user, client, stakeholder, teacher, or technical expert.

At this stage, your outcome does not need to be finished. You are trialling the basic structure, functionality, usability, and direction of your outcome so you can decide what to improve in Sprint 2.

Trialling helps you find out:

• whether the purpose of your outcome is clear

• whether the basic structure makes sense

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

• whether anything is confusing, missing, or not working as expected

• whether the outcome is starting to meet end-user requirements

• what should be improved next

Share your Sprint 1 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 basic structure, functionality, usability, and direction.

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 2.

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

This review should show where your project is up to and what needs to happen before you begin Sprint 2.

Your project board should now show:

• tasks that were completed

• tasks that are still in progress

• tasks that were tested or reviewed

• tasks that need fixing or improving

• any new tasks added because of testing or feedback

• any Sprint 1 tasks that need to move into Sprint 2

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

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

Move your cards into the correct columns, such as:

• Done - tasks completed during Sprint 1

• Testing / Review - tasks or 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 1 review prompts

• What Sprint 1 tasks did I complete?

• What did I not complete, and why?

• What testing or feedback affected my next steps?

• What parts need to be fixed, improved, or continued in Sprint 2?

• Have any tasks changed priority?

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

Keep it brief

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

For example:

I completed the main structure, navigation, and first version of the homepage. I did not finish the gallery section because testing showed that the navigation needed fixing first. I have moved the gallery task into Sprint 2 and added a new task to improve the mobile layout after feedback from my end user.

Before moving into Sprint 2, save a clear backup of your Sprint 1 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 1 version of your outcome.

• Create a backup copy of your project folder.

• Rename the backup clearly, for example:
  ProjectName_EndOfSprint1

StudentName_Project_S1Backup

Game_EndOfS1_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 1 version and file it clearly as End of S1. This creates a safe checkpoint before you begin making Sprint 2 changes.