How do we define and document grenades up front?
How do we estimate the cost and schedule for grenades?
This kind of question is common, but there is another question that is less frequently asked:
"How much fun will grenades be?"
Anyone who has played Quake, Halo or CoD, knows how fun grenades can be. Who hasn't belly-laughed at seeing an opponent run off with a plasma grenade stuck to them...both of you knowing that something bad is about to happen?
"How fun?" is a critical question and it should be balanced with the other questions. The reason it usually isn't is because fun is uncertain. It's a question that concerns those who are held accountable for schedules and budgets (or brushed off as a metacritic target). As a result, schedules and budgets often trump fun. They trump quality and as a result, lead to trumped sales.
Fun requires innovation and iteration. Innovation and iteration can be at odds with budget and schedule. Dramatically so. They need to be balanced. We've all been on projects or seen post-mortems where teams defy stakeholders and make something great or, alternatively, blow through years of budget and schedule goals trying to make the perfect game. We can't leave it to a team's passion alone to decide how good a game is. It has to be part of the business model and process.
The balance between schedule, budget and fun cannot be established in a big document up front or a Gantt chart. It has to be iteratively guided by someone who can create a balance between development and business. In Scrum, this the main purpose of the Product Owner (PO).
Back to Grenades
But first, let's step back and look at the life of a grenade through development:
A grenade feature might start life as a simple user story:
"As a player I want to be able to throw grenades at enemies to destroy them"
Depending on how many shooters your studio has shipped in the past, you might have more detail up front, but this is a double-edged sword because sequels often don't innovate as much. So let's assume this is the first grenade being created.
The first sprint will focus on getting the basic physics and control in place. We want the feature to "feel good" before we add polished assets, HUD elements or worry about how many grenades we are carrying in inventory.
During development , the team and product owner will gain knowledge about the fun, cost and schedule of grenade tossing and innovations such as "sticky plasma grenades" will come up. Innovating and iterating on what is fun is a critical aspect of what teams do. There is no measure for that.
Most features take longer than a single sprint to complete, but we want to minimize the amount of distance (time and cost) required to make the grenade "shippable". This distance is called debt. Lower debt allows balanced decisions to be made along the way based on fun, cost and schedule. Large debt results in schedule and cost factors dominating decisions on fun. Many of us have seen looming deadlines force us to cut features that are 90% complete. Establishing standards of how much debt can be carried forward from sprint-to-sprint during a feature's development is useful.
Velocity, most commonly expressed as story points or ideal days of work accomplished per sprint, can create a lot of confusion and an overemphasis on velocity can collide with finding fun.
Velocity is an excellent tool for forecasting, but when it becomes the primary measure of team performance, it can become counter-productive.
Let's say we estimate that grenades at 10 story points. Team A finishes grenades in two sprints, while team B takes three. Is Team A a more productive team? I can't tell you. Maybe Team B spent extra time making grenades an innovative and fun experience. Maybe Team B makes a game that sells 10 times as the game Team A's makes...
Velocity measurements are important, but they can't outweigh the judgement of a good Product Owner working with a motivated team.
Frequently Asked Questions
A number of questions related to this topic come up:
How much should we document and schedule up front?
When a excessively detailed grenade design and schedule is created up-front, teams are often temped to spend less time on finding the fun and rush to implement assets, HUD elements inventory details, etc because there is an assumption that the questions have been answered. This doesn't mean we don't do any planning up front. My rule of thumb is to start a plan on what you know about something and continually improve the plan by iterating. Effective agile teams spend more time planning than traditional "waterfall" teams. The difference is that agile planning is more evenly spread throughout the project.
How do we communicate cost to stakeholders if we don't know it up front?
One time I estimated it would take 2 days to tune a vehicle's tire friction model and it ended up taking 2 weeks. It was a necessary and unanticipated cost. The important thing is that I didn't decide to invest this time on my own. There was a conversation between the Product Owner and me on a daily basis about how driving felt. The Product Owner was accountable for the cost versus fun tradeoff, not me.
Same goes for the grenades: There needs to be an ongoing conversation about the physics and control here. Does it feel good? How much skill is required for aiming? Is the damage settings too high or low? All of these questions will impact the cost and schedule. This is where the product owner needs to weigh in. Through prioritized course correction, all the while keeping debt as low as possible, an agile team can control quality, cost and schedule better than a non-agile team.
What's to prevent features from wandering out of control?
Agile mustn't result in a free-for-all where the team implements anything they feel like. The Product Owner guides if-and-when innovations are taken advantage of. For example, if our shooter takes place in World War 2, plasma grenades would not be appropriate. Sticky bombs that use socks and grease would be.
On the other hand, maybe grenades doesn't end up feeling fun in the game and the Product Owner doesn't want to spend any more time and budget on them.
So this means we plan as little as possible up front?
No! Let's distinguish between identifying what's possible early, which is good, from making too many decisions up front, which is not so good. We'd rather make decision as we learn what is fun and how much it will actually cost. When we make decisions at the start of a project in a document or schedule, we're making decisions when we have the least amount of knowledge. That's usually when we make the wrong decisions.
Rather than try to come up with a very detailed design and task schedule that attempts to predict too much, a product owner can "cost box" and/or "time box" features. Cost/schedule plan for grenades early in the project might be nothing more detailed than:
"We'll spend eight people-months on grenades over the next two month release. We can't say exactly what the grenades will do right now, but we'll refine the plan as we go along and share it with you every sprint."
The stakeholders may request more detail about grenades, which might result in a few pages of detail, but over time, as teams and Product Owners build trust with the stakeholders, such demands diminish.
What other questions are you being asked (or are asking)?