Whether or not your workflow management tools include a kanban board with a workflow process via an actual (low-tech) office wall or having a (high-tech) virtual agile software board, you want to avoid having too much WIP (work in progress). If there is too much WIP, 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 to be obscured and hidden.
Here’s an example of a comprehensive status workflow automation from beginning to end:
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
A more simplified (and recommended) view of this workflow process would look like this:
To Do –> In Progress –> Done
In either workflow solution, it is in everyone’s best interest to place WIP limits. Before your sprint would start, you should 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.
[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]
