How do I manage a cross-functional AR project using the Agile Scrum framework?
I’m a Project Manager leading a team of 3D artists, Unity developers, and Computer Vision engineers. We find it hard to fit 3D asset creation into two-week sprints because high-poly modeling and rigging take longer than traditional coding. How do I adjust our Scrum ceremonies to handle the different "cadences" of artists versus developers without losing team cohesion?
2025-11-20 in Project Management by Lisa Ray
| 6432 Views
All answers to this question.
Managing AR projects requires a "Staggered Sprint" approach. Artists usually need a one-sprint head start. In Sprint 1, the artists create "Low-Poly Proxies" (placeholders) that the developers use to build the functional logic and tracking. By the time the developers are ready for "Polish" in Sprint 2, the artists provide the high-fidelity assets. This ensures that the developers are never "blocked" waiting for a final 3D model. During the Sprint Review, demonstrate the functionality with the placeholders first. This allows you to pivot the UX early without wasting 40 hours of an artist's time on a high-fidelity asset that might get cut from the final build.
Answered 2025-11-22 by Margaret White
Are you finding that "Technical Debt" accumulates faster in AR because of the constant updates to the underlying ARCore or ARKit SDKs during your dev cycle?
Answered 2025-11-24 by Steven Wright
-
Steven, that’s a constant battle in the AR world. Every time Apple or Google drops a new OS update, it can break the tracking logic. We’ve added a "Maintenance Buffer" to every third sprint specifically for SDK updates and regression testing. If you don't account for this "External Tech Debt," your project timeline will slip. As a PM, you need to educate the stakeholders that AR development isn't just "building the app," it’s maintaining a bridge between the physical and digital worlds that is constantly shifting due to OS-level changes.
Commented 2025-11-25 by Paul Robinson
We use a "Shared Asset Library" in Perforce. It helps both artists and devs see the progress in real-time and prevents the "version control nightmare" that often happens in Unity.
Answered 2025-11-26 by Karen Scott
-
Karen's right. Having a single source of truth for assets is vital. It stops developers from using an outdated rig and prevents artists from wasting time on a version that’s already been changed.
Commented 2025-11-27 by Lisa Ray
Write a Comment
Your email address will not be published. Required fields are marked (*)

