Production Postmortem

Stumblebumps Postmortem Blog

Hello all, and welcome to the Producer postmortem for the launch of Stumblebumps Unite. This will be a breakdown of the entire production process for the game: what went right, what went wrong, and what I’ve learned from this experience.

Here’s our version of the burndown chart showing how much work our team did throughout the 14 weeks of development. Here’s some of our statistics

Points Assigned: 790

Points Verified: 764

Points in Verify: 0

Points in Complete: 764

Cards Assigned but not moved: 18

Final Velocity: ~109 points/sprint

Overall, we had quite a productive 14 weeks. While we did have a few user stories that we couldn’t complete by the time the project was finished, we also didn’t want to risk adding features that could (and probably would) cause our game to malfunction. Overall, I’m glad we ended with the velocity we did, as I believe we achieved our goals of making an awesome game while balancing the features we wanted and needed to have. We were ahead of our ideal velocity for our entire development, meaning that we were moving at an increasingly fast pace compared to the scope of our game, allowing us to implement new features. We did slow down toward the end, but this is largely due to not wanting to add more assets into the game that could increase implementation time and cause issues.

WHAT WENT RIGHT

Aesthetics

Something that went right from the beginning was us setting up aesthetics from the get-go. We wanted our game to have a consistent theme that mixed games like Fall Guys, Mario Party, Little Big Planet, and Stumble Guys for a cutesy, child-like aesthetic that adds to the mascot of our game. Doing this gave our team a great jumping-off point for art assets, but also an aesthetic that people both internally and externally have sung their praises for. 

Feedback

Throughout development, our team was given feedback from both the leads and the playtesters of the game. I was very appreciative of the fact that the team was able to understand and act on the changes that were asked of them. This was particularly grueling with level design because of the amount of revisions that they went through.

For example these two images are captures of the same level, but significantly altered from beginning to end of development. Aside from the visual updates, the actual gameplay loop of the level was changed to accommodate player feedback by making the beginning section shorter, putting lots of chaotic props inside the dollhouse itself, and encouraging player-on-player interaction.

WHAT WENT WRONG

Feedback

During the project, I was unsure of how and when to move cards back that needed verifying. While I could verify that work had been completed easily, it became important for us to begin giving more constructive feedback on user stories and asking the team for revisions as opposed to giving entirely new cards for a task that we are asking for. Verifying the workload for a project like this takes a lot of time and requires communication, so I would’ve tried to spend more time checking the work against the design goals of the game, espeically in areas like level design and 2D art since those seemed to be areas of struggle for the team. 

Team Organization

Another thing that went wrong was keeping the teammates who were our MVP’s from doing work that was outside of their tasks assigned. This is a bit of a smaller issue, but I do feel that I could’ve done a better job managing the workload of the teammates with high outputs so that their work was organized and prioritized. While it’s awesome to have highly productive team members, it’s also important to keep scope and priority in mind, and we missed implementing a few systems because I had to balance letting my MVPs do their work how they wanted vs what we needed for the project as a whole.

WHAT I LEARNED

Ultimately, the process of verifying user stories for a team of cross-functional team members takes a lot of time, especially when the team reaches up to 14 people in size. I learned how to better construct feedback for team members, giving reasonings for why the feedback is there, and suggestions for changes that can be made.

I learned how to push and pull team members based on outside factors, workload constraints, and time. Many times I would try to pull my hard workers away from the project and prevent them from pulling work all-nighters so that they didn't face burnout. I would also try to push my team members who didn't have as many cards to explore and try new things so that their efforts could be rewarded. 

WHAT I'D CHANGE

From a producer's perspective, I would've tried to do a better job preparing for future sprints in Jira as soon as I got a sense of my team's average velocity. While having an organized backlog helped to get kickoffs going, it might have saved even more time if the sprints were pre-made and ready to go with tags, epics, and fully fleshed-out user stories.

To the dismay of many of my artists, I would've tried to push for more 3D assets in the game later on as opposed to making cosmetics and skins, even though they were fun to do. This might've helped alleviate some design constraints later on in the project. 

WHAT I'D DO AGAIN

I would continue to maintain a similar or even slightly higher level of communication with my teammates. I would do near-daily check-ins on the project and I think that my dedication to making sure that our design was as good as it could be was important to me, since I saw myself as the person who was in charge of making sure that the game's final version was as close as I could get it to it's potential. 

CONCLUSION

Stumblebumps Unite has been the most intense development process I've ever been a part of and I'm very proud of the game we've made. I'm thankful for the awesome team I have and for the hard work, they've put into the project. We hope to continue the game further and if you have read this far, special thanks to you!