While I have many stories of release planning, I like to share this one.

Getting started… a little late

I was coaching this game team/organization. The original plan for the next game called for about 6 months of design and development. However, due to other pressures, a lot of things were prioritized over this project and when the first people were able to start the work, only three months were remaining. There was hope that using Agile could help them speed up the development (through prioritization, backlog refinement and faster development), but it was still known that it will be tough.

At the beginning of the work, the game concept was available. A backlog had been built collaboratively with the team. For the first two sprints, only half of the team was available, and they started on the most critical stories. During this time, the backlog was radically refined and prioritized (i.e. features slashed), up to the point that PO started to be concerned that “there was no fun left”.

The Wall

At the beginning of the third Sprint, the rest of the team joined in, and on the third day of the sprint a release planning meeting was held. At this point, the team estimated the size of the items they had already completed (in story points) and used them as a scale for remaining items in the backlog. Based on the stories completed, the estimated total capacity of the team (for the rest of the planned sprints until release) was about 350 points (give and take a bunch). The size of the remaining backlog was estimated at 1300 points.

The lead dev’s estimate of their chances of success went from “optimistic 20%” to “definite 0%”. The sprint was terminated. Everybody scrambled to figure out a new approach with even a slight hope of success. The CEO could not find a feasible solution by extending the release date or otherwise renegotiating the contracts with the publisher. The team looked at their work and tried to figure out simpler ways of reaching the goal.

The New Plan

Luckily, the team’s previous game had a lot of similar elements as this new one (which was kinda considered “2.0” in many respects). However, it was considered severely lacking in technical quality (though it did work). Thus the team had planned to rewrite the core architecture to allow for future extensibility. Upon closer reflection, the team felt that it was possible to return to the previous game and simply modify and extend it to enable the new game design. A new plan was created that would allow them a shot at successful delivery, assuming that they could meet the weekly goals successfully.

Prior to this planning event, the idea had been to practice and implement Scrum in this project. It was decided that there was simply no time to practice, but they decided to continue with the team level elements that they had learned already. Also the new plan did resemble a Scrum flow with its weekly goals and they did review the plan weekly. They also tested a lot each week to ensure it was working sufficiently well. They also ran a beta test alongside the development during the last month.

During the remaining two months and a bit, they actually were able to create a version of the game they were able to ship to publisher and game reviewers. And they also took Steam to use, allowing them to refine/polish the game post-gold since the platform allowed for a forced update upon installation. While it wasn’t the game originally envisioned, it was good enough. And, the team actually did without a similar crunch as they previous releases (but it was still tough 2 months, just much less pressure in the last month and some). So they attributed a lot of the success and reduced stress to the Scrum coaching.

Aftermath

Irony of the story? After the release of the game they decided that they didn’t want to make games like that anymore. So any refactoring of the architecture for future would’ve been a wasted effort. Realizing that they were running into a wall ended up saving huge amounts of effort for them (against an essentially fixed payout for game delivery).

And they did continue using Agile ideas in their future games. They’ve been happy with the increased team collaboration and have continued with the new culture. And the lessons about user stories game them a very good foundation to create increasingly growing game versions instead of “everything at the end”.

If that planning had been any later, it would’ve been a disaster. Any earlier and we might’ve not been able to see it as well. And without the coaching it would’ve been a huge mess for everyone. While this is speculation on my part, the coaching maybe saved the company.