TaskPaper 3: Insert Started Tag

Updated for TaskPaper 3. The original script is here, with a little more info.

function AddStartedTagWithDate(editor, options) {
  var today = DateTime.format('today');
  return editor.selection.selectedItems.map(
    function (item) {
	  item.setAttribute('data-started', today)

  script: AddStartedTagWithDate.toString()

TaskPaper 3: Insert Created Tag

Updated for TaskPaper 3. The original script is here, with a little more info.

function AddCreatedTagWithDate(editor, options) {
  var today = DateTime.format('today');
  return editor.selection.selectedItems.map(
    function (item) {
	  item.setAttribute('data-created', today)

  script: AddCreatedTagWithDate.toString()

TaskPaper: Insert Started Tag

It’s not really enough knowing when you added a task to your list and know when it was completed. I mean, it always feels good to wrap something up, but it’s incredibly helpful to know how long that thing took to complete. Over time, you can use the ‘working time’ metric to tune your pipeline. Besides, I really dislike leaning back in the chair to rack my brain in order to remember exactly when I started working on a task. It’s also nice knowing how long something sat around waiting to be worked on. That’s why I whipped up Insert Started Tag.

on get_date()
	set currentdate to do shell script "date +%Y-%m-%d"
end get_date

tell application "TaskPaper"
	tell front document
		tell selected entry
			make tag with properties {name:"started", value:my get_date()}
		end tell
	end tell
end tell

Gamestorming the Benefits of Firefight!

Gamestorming the Benefits of Firefight!

We’re at the stage now with Firefight! where we’re really working on marketing. I’ve got to be honest with you, it can be tough for me. It’s not a moral issue. It has more to do with spending so much time creating and fabricating that it’s a big context switch. Sure, we’ve established strong design goals but those don’t typically directly translate to benefits or even features that a potential player can relate to. How did we translate those technical bits of game geek speak into benefits and features? We Gamestormed it and went from this:

To this:

It was inspired by the Cover Story game. But instead of using it to bring forward new ideas we used it to jump in and focus on what’s important from the perspective of potential customers.

The Skinny On Agile Game Design – Part 3: The Firefight! Board

In the previous Agile Game Design post we covered how to create a basic Kanban board that could be used for just about any endeavor. This time we’ll take a look at a board used specifically for game design. It’s the one that we use here for Firefight!.

Definition of Done

This version of the Kanban board has something new that we haven’t seen yet, Definition of Done.

Each column has its own definition that items in that step must meet in order to be called done. The definitions not only help to get everyone on the same page but they also act as reminders.  For example don’t worry about formatting and paragraph spacing when working on something in development. That’s not part of Development’s definition and odds are that it will be wasted effort.

The definitions are not meant to be inhibiting. If they are then they have to be changed. They’re there to facilitate getting things done  while protecting product quality.

The Columns


The items stickied in this column are pulled out of the backlog that we manage off-board. In our case we use Circus Ponies Notebook.

Think of Next as a slightly more sophisticated To-Do list where items of higher priority (as compared to those still in the backlog) are staged on the board.


Work In Progress Limit: 2

Items pulled into this column are analyzed to determine if they really are what we think they are.

If an item is too large (too many parts) to flow across the board then this is where it gets split into smaller chunks. Priority chunks are left here (respecting Work In Progress limits) while the rest are moved back to Next.

Next and Analysis function together to minimize wasted effort down the line.

Definition of Done:

  • Goal is clear: The objective is set. The item’s purpose is known.
  • 1st tasks defined: This is about creating momentum. When the item is pulled into Development the developer can get started right away. He doesn’t have to make any guesses.


Work In Progress Limit: 3

This is where you make sketches of ideas and hash them out. The skeleton of ideas get flesh put onto them and are molded according to vision. At the end of this stage they only have to be beautiful ideas not pretty to look at.

Definition of Done:

  • Unambiguous: In context of game design this means that the item or rule can be understood by others.
  • Component is captured: This means that it has been written down or is in an application available to everyone on the team.
  • Integrated and Tested: The item or rule makes logical sense and does not introduce unintended consequences.
  • Ready for Write-Up: The item is ready for the next step.


Here is where the product of development is refined for release.

Work In Progress Limit: 3

Definition of Done:

  • Written for final presentation: The item’s text is ready to be read by the outside world.
  • Retains design intent: Nothing was lost in translation.
  • Ready for acceptance: The item is ready for the big review.


Items pulled into Acceptance are looked at with a discerning eye. If they pass muster then they are given the thumbs up and are moved off the board and logged. If it’s thumbs down then we begin exploring the reasons why so that problems can be addressed.

Definition of Done:

  • Reviewed and given Thumbs-Up.
  • Ready for play.


So there we have it. The Firefight! Kanban board for developing ideas into functional game components fit for use in the field.

But wait a second! Where’s a Play Testing column? Isn’t testing important? Heck yeah it is. Our old board had one when we were doing active play testing. But we’re beyond that now and our board reflects our current workflow. That’s one of the nifty things about Kanban. It fits you.

The Skinny On Agile Game Design – Part 2: I Think I Kanban

In this article we’ll create a basic Kanban board that can be used for game design or just about any other kind of project. But first…

What is Kanban?

Kanban is a bit of a complex term. It is both an approach to development, in our case, game development, and it is also literally means “visual card” in japanese.

A Kanban board is a visual representation of your design workflow that uses cards or stickies to represent individual features (and sometimes tasks) to be completed. Cards are affixed to and flow across the board as work progresses. Let’s take a look at a simple example.

Our basic board looks a lot like a classic to-do list but there are two distinct features that set Kanban apart and make it tick; the “In Work” column and its accompanying Work In Progress (WIP) limit. All that you have to know now is that these bits are quite important. What they mean and their place in the system is covered later.

Creating and Using a Kanban Board

Step 1: Create Your Own Board
Go ahead and create your own board. Steal – err – copy the example but of course without the cards. Your board’s construction can be as simple as a set of columns on a sheet of paper or even better, columns on a wall made with tape.

Step 2: Add Items To Your Board
With board construction wrapped up, prime the system by adding items to the “To Do” column. They can come straight from your current to-do list.

Step 3: Start Using It
Select the items that you want to work on and pull them into the “In Work” column. When an item is wrapped up move it on into the “Done” column. Nice, quick, and easy.

But First We Gotta Talk (About Work In Progress Limits)

At this point you may be asking, What prevents me from pulling all of the items over to “In Work”? The answer is, one little but essential thing, the Work In Progress (WIP) limit. On the example board, In Work’s limit is 3. This explicitly means that at any given time only 3 items may be in that column.

Why are WIP limits important?
Coupled with at least one step between To Do and Done, WIP limits help prevent item traffic jams. Think of them working together as a valve for maximizing creative flow.

Who sets the Work In Progress limit?
You do, or in the case of a team environment, the entire team does. The beautiful part is that this number can be tweaked to better fit your workflow. The key is to do so only with careful thought. It should never be done on the fly or on a whim. Here’s why…

Don’t change them on the fly
Ad-hoc manipulation of WIP limits breaks the system. It simply turns the whole thing into extra meaningless work (waste) which is the antithesis of what we want. The voice of experience says to start low and carefully work your way up to a WIP sweet spot. But remember, improvement never stops. So, If at some point in the future a lower limit would make things better then go ahead and make the change.

From flow a myriad of other good things emerge.

Benefits of Kanban

With use, you will find:

  • Improved focus: Because you’re not distracted by the vague sense of how much needs done you can instead hone in on what you’re actually working on.
  • Improved prioritization: Because you are limited to focusing on a few items at a time you develop a keener eye for pulling items that will lead to improved flow.
  • Better risk analysis: Because you actively select items to pull into action you tend to give better thought to what you’re doing and its place within the project. You become freer to analyze and ask questions like, What can prevent this item from being delivered? Can I really hit the deadline?
  • Quicker turnaround times: You tend to complete items in a shorter amount of time because both you and the system become more efficient.
  • More value: Best of all, since you get better at what you do the opportunity presents itself to pack more value into what you’re creating.
  • Everyone on the same page: If you work with others then Kanban can make it easy to share the status of an item. All they have to do is look. This translates into less wasteful communication about status and more about the things that really matter, e.g. impediments, and improvement.

The Essentials of Kanban (How It Works)

You may be wondering why we waited all this time to talk about how Kanban works. Wouldn’t it be easier to know about this stuff ahead of time? Not really. Without seeing and walking through an example these things really don’t mean a whole lot.

The folks over at Crisp.se have done such an incredible job distilling how Kanban works that I’m not even going to try topping it:

  1. Visualize the workflow
    • Split the work into pieces, write each item on a card and put on the wall.
    • Use named columns to illustrate where each item is in the workflow.
  2. Limit WIP (work in progress) – assign explicit limits to how many items may be in progress at each workflow state.
  3. Measure the lead time (average time to complete one item, sometimes called “cycle time”), optimize the process to make lead time as small and predictable as possible.

Whoa, wait? What’s that last thing? Measure the lead time? Is this the first we’ve seen anything about that? No, it’s quicker turnaround times from the Benefits of Kanban section.

Measuring How Long It Takes

The simplest way to get started measuring is to jot the start date on an item when it goes onto your board. When the item is completed mark the finish date right along side. If you really want to get sophisticated then the dates can be entered into a spreadsheet or database. It really depends on your level of technical expertise though it’s probably a good idea to start as low-tech as possible. But no matter how you measure it is an excellent way to:

  • Learn how long it takes to do something.
  • Know how much you are capable of doing in a given period of time.
  • Identify where bottlenecks are in your process.


Remember, you don’t have to be perfect right out of the gate. The key is to gear yourself for continual improvement. Soon you’ll be beating your own expectations.

In the next article we’ll cover breaking the single “In Work” column out into multiple columns to better reflect a game design specific workflow. The current Firefight! workflow and Kanban board will be used as an example. Continue reading “The Skinny On Agile Game Design – Part 2: I Think I Kanban”