How Critical Mash uses the concept of Work-In-Process to keep projects moving smoothly

Web development projects that are far behind schedule and over budget often have a common characteristic, a large number of features that were started but never completed. Examples may be:

• a completed page without final or approved content
• product listings missing crucial information like prices, photos or descriptions
• an applet that fails on some browsers or edge cases; etc.

This is often due to the fact that teams run into an obstacle that prevents them from finishing the one feature, and decide to begin implementing another while waiting for client review, content or other inputs.

Next thing you know, despite hundreds of hours of work the project has multiple incomplete features that make the site unusable. Because the team has been jumping from feature to feature, they can also lose track of each feature's level of completeness and what needs to be done to complete each one. Going back and fixing all these issues or checking that features are complete takes even more time, pushing back the schedule and the budget.

Fortunately, this is avoidable by using the very simple idea of Work-In-Process.

Using the principle of Work-In-Process to keep your project on track

Work-In-Progress (or WIP) is one of the central principles of Agile Development. The idea is to separate all the to-do items in your project (defined as tasks, features, user stories, etc.) into separate columns of a task board based on their status.

A typical task board may have the following columns:

• Backlog: features the team hasn't started on yet (but will soon) sorted by priority
• Current: features the team is currently working on (your Work-In-Progress)
• Needs Review: Completed features that need to be reviewed by client
• Done: Approved features
• The icebox: potential features that may or may not be implemented

The current column represents the tasks that are work-in-process and the team should be focused on getting those complete and ready for client review. Completed features are moved to the Needs Review column. If a client reviews a task and decides it needs more work, she just moves it back to the Current column with a note on the needed changes, otherwise she marks it done.

When the number of tasks in the current column gets low or empty, the client and team choose one or more new tasks to start from the backlog, those get moved to the Current column.

Years ago, a task board would have been built on a white board with tasks written on Post It notes that could be moved from column to column. But now we have many task board web apps available that allow distributed teams to track their tasks in real-time.

Such an app might look like this…
[Task board illustration]

As you can see from the illustration, its easy for team members and the client to see exactly what’s being worked on, what needs reviewing, etc. The task board provides all this information at a glance. Many task board apps also allow the user to click on a task to get more detailed information or make updates.

Before beginning to implement a new feature (often called a User Story, which I'll describe in a later post), the team should know what is needed to complete the feature and make sure deliverables arrive on time, and agree to a testable definition of a working and shippable feature. Clients or project owners should be encouraged to review and approve features in a timely manner.

How this helps

When your project's tasks are organized in this way, it's very easy to see when the number of items in the current column gets too long. This is a clear indicator of your project's health that's available at all times.

The backlog also helps catch problems before they begin. The team can periodically check the backlog of upcoming tasks and decided what content they need, or questions answered before they start a task. This assures that tasks are completed quickly.

Conclusion

Following the WIP principle not only helps keep your project on track, it also gives you the option to publish your site incrementally as features are complete. (See Rethink: When do you go live?) This is because you'll only have a few incomplete features at any one time. And if you're implementing the most important features first, those incompletes can be quickly finished or turned off in order to have a shippable product.