Successfully changing direction working in an agile manner.

What went wrong

It became clear to me that I had been far too optimistic with my plans for the upcoming module. By attempting to fit in my four sprints from my BMX project in line with the module learning objectives, I felt as though I would be skimming over content rather than embracing it as part of my project. For example, when considering sound design, I was looking for ways to shoehorn it into the application as a whole, whereby in reality it may not be suitable for all parts of the app in the same way that it can be useful in games.

What went well

I kept to the agile manifesto and quickly responded to my over-ambitious plans by redefining my sprints. I decided to focus my efforts on creating a much improved BMX builder segment and begin working on that sprint first. This was very effective, together with my much considered approach of prototyping first on paper, then directly in the browser with html and javascript. I managed to produce a demo for the end of the sprint to really help me flow into the next one.

What could be done differently

I lost the initial week of the module by spending too much time planning my sprints out for the entire project. Moving forward, I now have a rough project plan with a much more focused plan for the immediate sprint. This will make it easier for me to continue to be agile and adapt to changes of direction or obstacles.

SMART goals

I have realigned my sprints as follows:

Sprint 2 - BMX Builder Iteration: continuing on from the initial demo:

Week 1 - Plan the entire user journey from start to finish

Week 2 - Implement the full experience as a development of the initial prototype

Week 3 - Conduct user research testing

Sprint 3 - Product polishing: improving coherence across the app between branding, features and presentation.

Sprint 4 - Product Optimisation: refining code and assets to serve a fast application that follows coding conventions so that it is easy to read and edit.