Friday, May 22, 2015

Level of Detail for Product Backlogs

Replacing a 300 page design document with a product backlog filled with thousands of small user stories doesn't provide much benefit.  Responding to uncertainty, emergence and change requires a plan which is flexible, communicates the game's vision and doesn't try to document uncertainty away.

Games need a product backlog with a couple of hundred stories at most.  Upon hearing this, a question often asked is, "how do we encompass the scope of a large game in just a couple hundred stories?

The Level-of-Detail Metaphor

A useful metaphor to answer this question is the "Level-of-Detail" (LoD) technique often used in video games.  This technique reduces the workload of a renderer by selecting one of several versions of an object to draw based on how far it is is from the camera.  In the figure on the right, a distant boat will first use the low-polygon model on the bottom.  As the boat approaches the camera, it switches to using the higher polygon (or triangle) models above.  Ideally, as the boat approaches, you won't notice the models changing (old-popping).

The reason for  using LoDs is that graphics engines and hardware have limits on the total number of polygons that can be rendered at 30 to 60 times a second.  If you want to have hundreds of boats shown in your game, using LoDs is a common way to render them.

LoDs for User Stories

The same approach is used for the product backlog.  The figure below shows some example LoDs for user stories:

Just as LoDs allow games to show a full, complex world on the screen, the LoD approach to product backlogs allows you to encompass the entire vision for the game in one view.  Highly detailed documents or backlogs don't allow you to "see the forest through the trees" and, as with a forest, are easier to get lost in.

Level of detail is increased through the practice of splitting stories.  You'll find some examples there.

Thursday, May 21, 2015

Acceptance Criteria: or How I Learned to Stop Worrying and Love Conditions of Satisfaction

"Of course, the whole point of a 
Doomsday Machine is lost, if you 
*keep* it a *secret*!"  
- Missing acceptance criteria?
A definition of done applies to all product backlog items, but sometimes you need to define a set of important requirements that are unique for individual stories before they are worked on.  These are considered “conditions of satisfaction” for the product owner, or acceptance criteria.

Example: As a player, I want to see a Message-of-the-Day (MOTD) from the developer so that I learn useful things about the game.

Some acceptance criteria for this story might be:
  • The MOTD window may only take half the screen.
  • It’s only shown the first time someone starts the game during a calendar day.
Keep in mind that acceptance criteria shouldn’t be a huge list of design specifications.  These are a limited set of specific “must do” criteria that the team needs to know up front.

Types of acceptance criteria:
  • Specific functionality known up front (above).
  • Special, non-functional requirements (e.g. memory or CPU performance limits), for example “The game should have ten of these effects running with less than 2 milliseconds per frame cost on the target platform”.
  • A set of expected behaviors for a subset of features, such as needing persistence in saved games or needing specific tests for online gameplay.   
  • Known areas that will be incomplete.  For example, if you’re implementing a jump feature, but don’t have enough animation support (and have failed to get more), an acceptance criteria might say “some animation transitions will pop”.
Good acceptance criteria will:
  • Have a clean pass/fail, testable state.
  • Won’t dictate implementation details.
Who and When?
Acceptance criteria can be added to a story any time before, and during, sprint planning.  Usually they’ll be added in release planning, grooming and sprint planning with greater detail added as the sprint work approaches.  The product owner doesn’t have to be the one to identify them all, but should be present when they are captured.  I prefer to have the team there as well asking questions and suggesting acceptance criteria along the way.  One useful approach is to have a member of QA or a developer capture any acceptance criteria during discussions of the story, especially in sprint planning.

The Point
Acceptance testing will focus the team on the outcome as much as the means of getting there.  It allows the business side to build trust with the team and to improve how they communicate their needs.  When trust exists, the business is less likely to worry about the sprint and interfere.

Wednesday, May 20, 2015

Help! My Scrum Master is Running the Sprint!

“Hi, I had a question.  Our Scrum Master is acting like a manager, running all the meetings and assigning work.  This is what they did before Scrum.  I thought Scrum meant the team did this stuff?” - A developer

The values of Scrum apply here.
Scrum! Scrum! Scrum! Scrum!

The sprint is the team’s commitment to a goal.  True commitment to the game and continuous improvement requires a level of ownership, otherwise it’s an environment of compliance and people don’t engage as well with that.

The barrier to allowing ownership is fear.  I often hear the micro-managing Scrum Master’s fear of what will happen if the team doesn’t follow their leadership.  "They might fail!", they cry.   There is often an underlying suspicion that others on the team are not competent because they'll make mistakes.   The news is that competence doesn't mean you don't make mistakes!

Allowing teams to make mistakes and safely fail from time-to-time requires trust and courage.  Trust requires respect.  A lack of trust and respect is a cultural root of evil.  When I see locked supply cabinets, dictated core hours or time-sheets, web filters, people referred to as “resources” etc. I know that the true adoption of Scrum will be a bit harder.

How can this be done?
Courage is required
Shifting from a mindset of individual compliance to team commitment requires courage all around.  The Scrum Master and the team must summon the courage to take chances and fail every once in awhile.  Emboldening the team to find this courage is more challenging than micromanaging via a task spreadsheet, but it’s also more fulfilling.  It doesn’t happen overnight, but trust and respect can be grown.

Scrum Masters can start with some simple things:
  1. Silence yourself! Stop doing all the talking.  Learn to allow awkward silences.  The team will fill the silence with their own ideas and solutions.
  2. Ask questions, even when you know the answer.  Teach them to catch fish rather than giving them fish to eat.
  3. Be courageous.  Demonstrate respect and protect the team.
The development team assumes a part of this challenge as well.  It’s often hard for them to shift from being assigned tasks to accepting responsibly for planning and executing their own work.  Respect and openness among each other is critical.

For example: if an artist is having problems getting code to work with a model, the entire sprint goal is threatened, but the team's focus on their shared goal should guide them to solve this problem on their own.   There is no need to blame the artist for not solving their own problem.  There is no need for someone wearing a manager’s hat to assign an engineer to fix the problem.

Does this mean managers/producers should be fired?
Don't expect leadership to
be overthrown, but leveraged
An underlying fear from managers or producers jumping into the Scrum Master role is that they should continue doing what they've been good at in the past or they'll be let go.

In the ten years that I have been training teams to use Scrum, I haven’t seen this happen.  I’m not saying it never will, but most stories I hear reflect my own as a manager in a studio that adopted Scrum.

I found that as teams became more self-organizing, there was a growing part of my time that needed to be filled with other things.  Eventually, about half my day was freed up by not micro-managing.  This wasn’t bad because the work that teams took from me was never the work I enjoyed doing.  So, I joined a team as their product owner and ended up enjoying the work far more as I was closer to the game and the people making it.

This might not be the path for every manager.  Agile should lead a studio to ask what practices and roles are benefitting their games and the people making them and what parts are not.  Again, this can threaten the status quo, which is why a lot of larger, established studios have a harder time adopting agile.

"Now I can make cool movies about
monkeys taking over the world!"
The bottom line is that these values have to win out for you to have full success with agile.

Tuesday, May 19, 2015

The Scrum Values

The Scrum Values

  • Focus. Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
  • Courage. Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
  • Openness. As we work together, we practice expressing how we're doing, and what's in our way. We learn that it is good to express concerns, so that they can be addressed.
  • Commitment. Because we have great control over our own destiny, we become more committed to success.
  • Respect. As we work together, sharing successes and failures, we come to respect each other, and to help each other become worthy of respect.

Saturday, May 16, 2015

The Art of Splitting User Stories

Splitting stories—the act of breaking up large stories into smaller ones—is as much art as practice.

The strategy of splitting stories is to split them as late as possible to fit in a sprint just before the sprint that will take them on.  Think of it as playing the classic arcade game Asteroids: you only want to break up the large asteroids when they are an immediate threat to you or when you've cleared out the smaller, more dangerous rocks…break up too many of them too soon and the resulting cloud of small asteroids will kill you.

Similarly, if you break up a bunch of epics into a large number of sprint-sized stories, the resulting backlog bloat will cloud vision and diminish your response to change.

There are a lot of good tips on how to split stories, like this one.  In this post, I'm going to suggest some of the more common splitting techniques used for video game development.

A couple goals exist for splitting stories:
  1. Each of the split stories should have some value to the user.
  2. The split stories should be able to be prioritized against one another.
Below are a few of the common strategies and examples for splitting epics along with some reasoning for them.  The examples illustrate single suggested splits, but aren't the only ways the epics could be split.

Split along research/prototype dependencies: 
Example: As a player, I want to react to impacts.
A suggested split:
As a designer, I want to know where an impact occurs.
As a player, I want to react based on the impact location.

Reasoning: The first story allows some research on collision physics and helps the team and designer experiment with different strategies. (e.g. would a simple strategy of having high, mid and low collision volumes be good enough, or do we need something more complex?)

Split along conjunctions:
Example: As a player I want to smash wooden crates and doors open.
A suggested split:
As a player, I want to smash wooden crates open.
As a player, I want to smash wooden doors open.

Reasoning: Do the simplest or most important first.  Also note that the first of anything is usually more expensive, so this makes it easier to see costs by sizing these stories individually.

Split by progression:
Example: As a player, I want to be coached on the rules of poker and ways I can improve my home game.
A suggested split:
As a player, I want the game to have some first-time user experience (FTUE) tips for playing poker.
As a player, I want the game to give me tips for improving my home game.
As a player, I want the game to evaluate my hand strength and suggest the next move.

Reasoning: This split details some of the "ways" the player can improve with a progression of stories that are a bit more specific.

Other splitting strategies include:
Split by acceptance criteria.  Acceptance criteria often make perfect stories themselves.
Split by discipline capacity.  E.g. if you don't have enough animation support, then you might have to split off a "Add polished animations to..." story for the next sprint (after you've done everything else to avoid this).

There is one consistent splitting technique that teams new to agile have a hard time avoiding.  This is splitting stories along component design or discipline effort.  Teams new to agile are used to breaking up features into a plan to develop all the “parts”, which will become useful sometime in the future.

Example: As a player, I want a third person camera that can transition smoothly between a loose camera in open spaces and a tight camera in small spaces that avoids collision with the surrounding geometry.  

A poor split would be:

As a programmer, I want to create a camera manager that will handle transitions between all future cameras.
As a programmer, I want to implement a camera collision system that will avoid camera collisions or occlusions from the surrounding geometry.

The reason these are poor splits reflects agile values and principles that building emergent, working software is better than following a never-perfect-yet-detailed plan which delays that emergence.  A better approach to splitting might be:
As a player, I have a simple polar camera that follows me around.
As a player, I want the distance between me and the polar camera to be based on how close the surrounding geometry is.
As a player, I want the the camera to have a collusion box around it to avoid going into surrounding geometry.
As a player, I want the camera to linearly interpolate its position as a rotate.

There are several advantages to this:
  1. The rest of the team gets a camera sooner.  This allows work and feedback to continue (rather than finding “something else” to work on in parallel).  
  2. Unless you are in the position of being 100% certain of the requirements of the camera system (something I’ve rarely seen on a team), there’s less of a chance that the system developed will need major rework.
  3. Emergent development will often save a lot of time by identifying what we don't have to build.   I relate a story of this in another article.
I’m fully aware that there are some out there rebelling at this idea.  They’ll say “just give me the spec, let me go into my office, put on my headphones, and bang out the camera system…it’ll be much faster”. This is a very common attitude from cultures with more silo’d disciplines.  It’s very hard to for such organizations to shift the mindset from one whose primary goal is to crank out components at the highest possible velocity, to one which cranks out features of the highest possible value.

This is not to say there aren't features that can be fully planned and executed without iteration.  The trick is to not fool ourselves into the belief that we can plan away uncertainty.