Sort out your WIP with just one smart tip: limits!

WIP stands for Work In Progress aka work that has entered the development process but is not yet finished and available to a customer or user.

Whether or not your workflow management tools include a kanban board with a workflow process via an actual low-tech office wall or having digital agile software board like the ones in Herogami, you want to avoid having too much WIP on your team.

As a project owner or scrum master, if you allocate or allow too much WIP in a sprint, you may create too much waste or risk in the form of lagging partially completed work, or excessive waiting. Furthermore, excessive WIP will also cause blockages in your project due to obscure and hidden activities which will arise totally unplanned.

Different teams may adopt tailored workflows that provide different workstations. All workflows have one trait in common: work states are progressive. There is always an initial state, a final state, and a series of intermediate states that measure the progress of activities at a scale ranging from one team to another.

To exemplify here are a couple of workflow examples at the extremes of what we usually see in Agile teams.

First example (don't laugh, we've seen it happening):

New → Open → In Progress → Code Review → Code Committed → QA Ready → QA In Progress → QA Passed [or] QA Failed → UAT Ready → UAT In Progress → UAT Passed [or] UAT Failed → Closed/Done

We see the above actually happening in many teams: a complex workflow is one the first symptoms of organizations adopting Agile whithout being trained on the fact that any major change in their internal processes should aim at keeping things simple, actually to the very bare minimum. This is a very basic rule of change management in organizations of any size, yet it is outside the scope of this post, we will definitely reserve a post on this in the future.

A more simplified (and possibly recommended) view of this workflow process would look like this:

To Do → Doing → Done

Of course the latter workflow may not be the best workflow either, most likely it is too simplistic and may not reflect the actual status of the activities a task, a story or an issue is going through. Say, for instance, that an issue needs validation before being considered completed or “done”. In this case, the perfect workflow looks like:

To Do → Doing → Testing → Done

The above is what you actually find a the default workflow in every new project in Herogami. Of course in Herogami this can be totally customized on your needs by editing stories and issues workflow, even on a project basis.

In either workflow solution, it is in everyone’s best interest to protect the project success by limiting the number or items being processed at every step of the workflow: you want place WIP limits.

Before your sprint starts, you must be able to determine - based on the story points and team size - what the typical limits should be as per the agile team roles and team members.

These can then be calculated and factored to represent the overall WIP limits for your board to prevent too much clutter. However as you can guess, the comprehensive example above or any type similar to it, would be the most difficult one to set limits to, since the stories would be scattered everywhere across multiple statuses.

Like any complex procedure, it is best to break it down into smaller parts. A simplified board should be used as your dashboard view to get a consistently general view of progress.  Once you’ve scaled down your board as much as possible the WIP limits will become easier to manage. A notable mention is the status “Blocked” which can be shown with a more specific indication of which workflow the block occurrence came from, i.e. Blocked in Dev, Blocked in QA, or Blocked in UAT. This will further allow for a quick response to the blockages.

The example given above assumes workflow management processes are happening simultaneously, but it would certainly be more appropriate to create some workflows in later sprints or specific milestone date if you knew, for example, that UAT was coming at a much later time. The key is to keep it simple.

Grumpy Herogami, Architect

29 Jul 2017