The Scenario
Recently, I was put on a client’s project that was somewhat in jeopardy and, of course, had an exceedingly aggressive ship date. My job was to get the product out on time and to aid the management team in getting the team and project at large, back on track. On day one, the team informed me that they wanted to recommit to Scrum, something they had let fall to the wayside in the preceding months. It is my opinion, that Scrum, when strictly applied, can get in the way more than it helps. I think you need to shape Scrum to fit your project and team’s needs. For this article, I just want to concentrate on the estimation (Story Points!) side of Scrum.
The Goals
Since I came into production via game design, let me list the goals I had in mind:
- Easy to estimate – we needed to plan properly. You always need to plan properly. But scrum assumes you have time to figure out what Story Points mean for your team. It takes three months to determine Velocity. We had to ship in three months.
- Easy to understand – Story Points are confusing and tend to create controversy with a new team.
- Predictability – Our deadline was do or die. We needed to quickly be able to establish workload vs. capacity to hit our dates.
The Solution
The solution was pretty easy to arrive at and I am sure you have heard of it before. I had come across a similar solution with the first Scrum team I ever worked with and had used it with my most recent client. Brace yourself here, we are breaking the rules! Many articles will tell you exactly why you should not do this. But sometimes, you must make your own rules. Story Points = Time.
Here is the scheme we put in place:
- 1 Story Point – Less than a day
- 2 Story Points – a full day
- 3 Story Points – 2-3 days
- 5 Story Points – 1 week
- 8 Story Points – 1 week and some change
- 13 Story Points – 2 weeks
- 100 (we broke the Fibonacci here) Story Points – Really big, unknown, needs more info, not viable for a sprint yet
The Result
The upshot? Here is another nice bullet pointed list:
- We immediately understood our Velocity, or at least our ‘Ideal Velocity’. In a two-week Sprint, a developer should be able to complete ~13 Story Points. It was now easy to figure out what we should be able to do in a two-week Sprint and what simply would not fit in to the release schedule at large.
- It was easy for the team members to understand and apply the scheme. Planning was smooth and relatively quick. No confusion over “effort” or “complexity” or “relative sizing.” (all useful, but potentially confusing concepts)
- Management understood what the numbers meant, instantly. No fuzzy numbers.
- We shipped, ON TIME!
Let Me Sum Up
I consider this method to be a good “jumping off point” for a team getting used to Scrum and better planning in general. Over time, our notions of what 13 Story Points really meant evolved. As the team continues to mature and practice Scrum, things like complexity and how to deal with unknowns get folded into the process. At some future point, Story Points start to look a more like Story Points, not straight time conversions.
Scrum comes across as doctrine. You gotta do all the little bits or you will fail. But Scrum is just an evolution of the greater Agile methodology. Or an iteration. To my mind, with its own focus on iterations, Scrum itself should absolutely be iterated on. Project to project or even milestone to milestone.
How have you bent Scrum to your project’s will? Please comment below and thanks for reading!
About Tricky Fast Studios
Tricky Fast Studios is a small, Massachusetts-based startup game studio featuring long-time industry veterans with particular expertise building mobile and PC games and providing server solutions for them. We have developed mobile and PC games for Story Arc Media, the Game Show Network, Publisher’s Clearing House, Disruptor Beam, and others. We provide a full spectrum of game development services. We’re here to build your story!
For more information, email info@trickyfast.com.
