Coming here from TrackStudio's JIRA comparison page? You might want to read this first.

When, as we do, you write your specs on a wiki, keep track of your development tasks in an issue tracker, and eventually ship products that only exist as bits downloaded from a server, it's very easy to forget how much psychological impact physical objects can have.

Data exists in some ether that your mind never really has to deal with completely. Physical things have presence. They take up space. They can arrest your vision. When you move them they stay moved. You can fold, spindle and mutilate them as you wish.

Which is why the 'Wall of Death' is such a useful tool for getting developers focused on the task at hand.

Step 1: Preparation

All the issues marked as outstanding for the next release are printed out, two to an A4 sheet of paper. We find JIRA's "Full Content" navigator view works well for this, although you have to print through Opera, because no other browser correctly supports the CSS hint for a form-feed.

Step 2: Lightning Estimation

The issues are divided between the developers, who are asked to estimate their pile purely on gut instinct. Developers are free to swap issues if they feel someone else is in a better position to estimate a particular task. Estimates start at half an hour, and then increase roughly exponentially: one hour, two hours, half a day, one day, two days, four days, two weeks.

Estimates are written on the printed issues in some bright, unmistakeable colour.

Step 3: The Cull

Now you have your issues estimated, it's time to go through them again and make sure there is at least some sanity to your schedule. Add up all the estimates, compare them to when you feel you want to release, and cull your issues until the former fits into the latter.

Step 4: Build the Wall

Find a stretch of uninterrupted wall in easy reach of the whole development team. Blue-tac all the issues to that wall, grouped in vague areas of functionality. Also, co-opt a corner of a nearby whiteboard to hold the tally of estimated time remaining.

Step 5: Go!

This step takes a little more time. :)

The rules of the wall are:

1. Developers take an issue off the wall, and work on it until it is done
2. Developers must not work on anything that is not on the wall
3. Corollary to rule 2: unanticipated additional work must be filed in JIRA, then written on a card and placed on the wall
4. Developers must never take more than one issue off the wall at a time
5. Once an issue is done, the developer records the actual time taken in the other corner of the issue, dumps it in the 'done' pile, and updates the whiteboard.
6. Repeat until no issues remain on the wall

Why it Works

I'll be the first to admit that this idea is stolen largely from the way Extreme Programming uses index cards, just adapted to an environment that takes advantage (for good reason) of an issue tracker, and where the time-boxing of an iteration is often subject to the commercial necessities of having a complete, polished release.

• The wall focuses the team's attention on just how much work exists between now and the release
• The temptation to pad out features or to experiment is countered by the desire to mark the issue as done, and pull the next off the wall
• The state of the wall is a clear indicator of progress, and as it empties there is a palpable feeling of satisfaction
• Scope-creep is much harder when in order to accomplish it, you have to put a physical object that means "more work" in plain view of everyone, and adjust the whiteboard tally upwards
• As a bonus, you end up with a pile of paper that records differences between estimated and elapsed time

---

Update, September 1 2007. I was checking my referrer logs today, and found that this post had been linked from TrackStudio's comparison page for JIRA with the following text:

Choose TrackStudio if you are going to use the system both to organize work inside your company and to communicate with your customers. Atlassian developers uses JIRA primary to communicate with external users, but they do not use it to manage software development (you can read details here and here).

Not only is this statement patently untrue -- we use JIRA at Atlassian to manage software development. We also use it to track support, sysadmin tasks, even ordering books for our library -- it completely misrepresents the content of both of the blog posts it linked to. I guess they figure that most people won't bother to click through the links and read the posts for themselves.

I humbly suggest you read the remainder of their product comparison with a similar grain of salt. :)