When discussing lean techniques such as Kanban, we often assume that you understand the concept of work-in-process (WIP). That assumption is not always true. I am occasionally asked how WIP is defined in a software development (or an enhancement or maintenance project) and whether related work products, like test plans or documentation, are part of WIP for piece of code.
WIP is work that has entered the production process, but is not yet complete. A slightly more technical definition of WIP is all raw materials or partially finished product that are used or transformed in the production process. In a software development or maintenance project, WIP includes all of the work products or resources required to deliver valuable functionality. In software development and maintenance, WIP for the story will typically include code, documentation, test cases, test results and plans (just to name a few typical work products). All of these work products are WIP until the story is deployed in production.
In the Kanban: An Overview and Introduction we used a simple software development lifecycle to define Kanban and the concept of flow. Using a user story as an example we can trace the transformation from a card into implemented software. The story begins its WIP journey as soon as is pulled out of the backlog and then completes WIP journey when it has been deployed in production. The simple Kanban workflow we used in the past is shown below:
Using the example of simple piece of web functionality we begin with the user story, “As a SPaMCAST listener I want to see the description of the book by current interviewee so I can decide to buy the book.” As soon as I grab the card and put it into the analysis column it is WIP. This is true whether I start fleshing out the user story at that exact moment or later in the day. In order to complete this story it requires that I create a link to the book and embed that link in the blog entry for the podcast episode and then test the link to ensure that it works. The link is complete when the blog entry is in production and the story is no longer WIP. Diving down a little into the detail, when I create the book link I go to the booksellers site (SPaMCAST uses an Amazon affiliate account so that purchases of the books mentioned on the podcast support offsetting the expenses needed to provide the podcast) and select the link for the book. The next step is to paste the link into an Evernote document for documentation purposes. That Evernote document becomes part of the WIP connected to the story. Later if that the link is found to be wrong, not only does the link in the blog entry need to be changed, the link in the documentation will need to be updated. Nothing ceases to be WIP until the link is live on the website and it works correctly. As the story progresses the link is embedded it into podcasts blog entry, the link is tested using a simple test plan (the test plan is part of the WIP related to the story). During the process of finding the link and putting it into the blog entry and Evernote document, the story is being worked on,. When the story is is being actively worked on the story is moving through the process (flow). When the link is embedded and tested the code is complete and ready to be implemented. Ready to be implemented is not same as being implemented. In process for the SPaMCAST podcast, the story is still WIP, but it is no longer being worked on. The flow of the story has been interrupted. If the blog entry or whole podcast needed to be updated the link would need to be revalidated and potentially changed. The listeners of the Software Process and Measurement Cast will know that the podcast typically goes live on Sunday at 17:00 Eastern Time. As soon as the link is validated in production the story moves from WIP to complete.
When discussing WIP in software development it is easy to fixate on the functional software as the only part of the story when tracing WIP. In the example of the book link user story, the process I use to develop the link and ensure that it works includes code (HTML), documentation and a simple test plan. All of these work products are part of the completing the user story. Completion of one work product without the other leaves the story in an incomplete state and still work-in-process.
Software Process and Measurement 
September 25, 2014 at 12:21 am
WIP is for Work in Progress or work in Process?
September 25, 2014 at 10:04 am
Thanks. This is a useful reminder that limiting WIP doesn’t just mean setting limits on the number of cards in a column, but also eliminating the creation of any work products that don’t add value or replacing them with more efficient processes, like JIT face to face conversations.
September 25, 2014 at 10:57 am
Thank you. Value at a systems level must be understood and judged to make any effective process improvement.
December 30, 2014 at 11:56 pm
[…] have not already established a work-in-process limit (WIP), set one for each class of service. A WIP limit is the amount of work you will allow yourself to start and actively work on at any point. Work is […]
April 16, 2016 at 11:56 pm
[…] helps the team know where they are and how they can coordinate their own activities. The process of visualizing the flow of work identifies all the work in process (WIP). A side benefit of identifying WIP is that you […]
August 25, 2016 at 12:51 am
[…] beginning WIP limits for each task. Work in Process (WIP) limits indicate how many items any specific task should control at a time (being worked on or […]