Our two main goals of adopting agile is to (a) reduce waste and (b) find the fun first. By focusing on adding scope to the game in prioritized and "completed" increments, we hope to achieve these goals and avoid scrambling at the end to find it.
We develop our games in series of 2-3 week "Sprints". Each Sprint adds "vertical slices" of features that add to the value of the game. The game should be better every 2-3 weeks. We also have "Releases" which occur every 2-3 months (there are about 4 Sprints per Release). Releases are "potentially releasable versions of the game". We think of them as magazine or E3 demos.
As we wrap up another release, I had some observations about how we can do it better. E.g. how we can reduce the waste and improve finding the fun.
With the last 2-month release, we didn't really see much of the value until the final Sprint during which the team elected to work some overtime (the last weekend and some of the nights during the week). Although this was not a death-march in any sense, it's something to keep an eye on towards improving.
So I've been thinking about that.
One of the values of Scrum is its tools for creating transparency in what is going on. One of these tools is the "Release Burndown". This shows how many "Story Points" the team is finishing each Sprint. Story Points are measures of feature difficulty that are relative to one another (and most importantly, not tied to hours). It's been a very good measure of feature velocity when planning future releases.
During the last release, we saw a drop off of Story Point velocity towards the end of the release:
This diagram is used to illustrate what happened (it's not the actual Release Burndown, but simplified to make the point). The blue line shows the story point Burndown. The purple shows the value of the game (fun) from the customers perspective.
Ideally, I'd like to see the value grow at a steady pace. If it's not, then it implies that debt is growing. Some of the work going on is not reflected in the game.
Debt is unfinished work. We'll refer to it as "parts on the garage floor". Debt can be:
- Polish or tuning work
- assets that are left out or built too soon.
The reason is that lack of tuning prevents value. How many times have you played a game where an annoying behavior prevented you from enjoying it as much as your could have had it been fixed? You can see the effect of this in the diagram above; As the team shifts from working on stories to working on polish, the story point velocity decreases, but the game value increased at a much increased rate. We customers started enjoying it more and more as those annoying and distracted problems were fixed.
(One comment that comes up is that "all debt is not bad". That's the topic for a future post.)
So why did we have overtime at the end of the Release? Two reasons:
- The team elects to do overtime when the product value growth is near vertical and they are running short of time.
- You do it because you can't ship with critical bugs still in the product.
What should happen is:
- The team completes vertical slices of scope every Sprint.
- The scope is prioritized.
- When you near the end of the Release, your Scope velocity determines the Scope cutoff point. The lower value features are left off.
This is the hard part. There are two avenues of how to address this that need to happen:
We customers have to set the expectation for completeness every Sprint. We need to recognize debt and react to it. Recognizing debt in game development is hard.
The team needs to focus on value and not on stories and points. They get fixated on the Sprint Burndown and need to pay more attention to the game.