Feature Boards

A challenge in agile game development is managing cross-discipline teamwork where a wide range of skills is required.  As a result, following some practices and artifacts by-the-book doesn’t work as well as it does for software-only teams.  One of these artifacts is the task board.  These boards are used for teamwork transparency during an iteration and are a tool for the team to manage their day-to-day progress.  However, for a highly diverse game team, task boards are often modified.  This article is about one such modification, called a “Feature Board”.

Task Boards

A strength of the physical task board is that the team owns it.  A physical task board is always visible and requires no licenses and little training to use.  The only limitations are that it requires wall space and team collocation.  The photo above demonstrates some example modifications made by the team using it, such as adding columns for verification or colored cards for tracking different types of work (e.g. emergent work, bugs or impediments).

A problem that boards like this encounter is the lack of visibility of cross-discipline dependencies.  For example, let’s say a team is working on a number of player mechanics in an iteration, such as jumping, crawling and ducking.  There are three programmers and one animator among the team.  Halfway through the iteration, the programmers have the code working, but can’t fully test it because the animator is backed up with too much work.  Perhaps the animator is trying to work on all three mechanics at once or the task of animating one mechanic is harder than they thought, or there is a problem exporting the animations.  Creating awareness of these problems is one of the functions of the daily stand-up meeting and a mature team will address them, but sometimes a problem like this doesn’t surface until it’s too late in the iteration to do anything about it.  This is one instance where a Feature Board can help.

What is a Feature Board?

A simple Feature Board looks like this:

Instead of tracking tasks, a Feature Board visualizes feature development state.  The iteration (or Sprint) goal is on the left side and contains cards identifying features the team committed to implementing over the next 2-3 weeks.  The cards move around the board (not just left to right) during the iteration, depending on the work that is being done.  Each column on the board indicates the type of work being done on the feature at the moment.  The rows show which features are in progress and which features are waiting for work to be done.  As features are completed, they exit to the right of the board into the “done” column.  In this particular example, the features are prioritized in value.  Red features are the most important.  Green features are the least important and yellow are in-between.

How is a Feature Board used?

A Feature Board serves the team.  It shows them the state of each feature on a daily basis and leads to conversations that are necessary for a cross-discipline game team.

Take a look at the board above.  The board is telling us that the jump feature is having some coding done, while melee is getting some animation.  There are a few bug fixes that need to be done and one of them is being worked on by both a designer and programmer.
The board also raises questions.  For example:

The board won’t answer those questions, but quickly highlight them for the team to answer.

What are the benefits of a Feature Board over the by-the-book Scrum task board?

Feature Boards focus on feature progress, not task progress.
Too many times, teams get focused on completing tasks in any particular order and don’t worry about features being “done” until the end of the iteration.  Postponing “done” means features don’t get enough polish and tuning time.  As a result, teams release lower quality features.  Feature Boards focus the team on completing prioritized features over merely completing tasks in any particular order.

Feature Boards help balance cross-discipline teams.
Unlike software-only teams, a cross-discipline team of game developers can’t share as much of their work (e.g you really wouldn’t want me creating a texture or a sound for your game).  So it’s important to quickly identify problems with the flow of work.  Task boards don’t do this well;  They don’t visualize stalls and backups.  As a result, individuals end up solving problems by working on more things in parallel, leading to late integration, testing and tuning.  Feature boards show, dramatically and frequently, where the stalls are occurring, or soon to occur, which focuses a team's response.

Feature Boards help limit Work-in-Progress (WiP).  
In order to complete features sooner in an iteration, a team needs to work on fewer features in parallel and address issues or workflow problems that are stalling work or wasting time.  By separating the “In Progress” features from the “Waiting/Blocked” features, a team will see where work is piling up quickly enough to be able to do something about it.  Teams can even institute “WiP Limits” on the columns or rows to stop any new features being added when work is piling up too much.  This leads to different behaviors.  For example, when the team sees that testing work is piling up above, others in the team can help out.  There is no law of nature that says “only testers can test”.  By embodying WiP limits, Feature Boards can be a tool for encouraging such “out of the box” thinking.

“This looks like Kanban!  Why not just use Kanban?”
Some of these ideas come from Kanban (like WiP limits), but it’s not Kanban by-the-book.  While Kanban by-the-book is great for some work—work that is less exploratory, or follows a predictable flow of hand-offs from one discipline to the next—the Feature Board is better for teams that are working on unpredictable new features and “first-time” content.  Feature Boards fit best within a time-boxed iteration which has a lot of “swarming”.  “Swarming” means that there is an unpredictable flow of work between disciplines to create a feature and the feature will bounce around or iterate unpredictably before the fun is discovered.

Own It

The bottom line is that I don’t care what label you use (Kanban, Scrum, etc).  You need to find what works regardless of where it comes from and keep finding ways of making it work better.  That’s the agile mindset.

If you want to know more about Feature boards (such as what the feature cards or burndown charts used with Feature Boards look like), please follow my blog (http://blog.agilegamedevelopment.com)  where this article first appeared, for upcoming articles or my Twitter feed (http://twitter.com/ClintonKeith)