One Piece Flow

One piece flow is a concept from Lean and is the key to succeeding with Agile. One piece flow is exactly what is done when producing a hotfix. The only difference is that one piece flow is an intentional practice rather than something done in reaction to a critical problem.

There are four main concepts in “one piece flow.” Each story is done as if it was the only thing in the release, each aspect of developing a user story happens in rapid succession, there is as much done in parallel as possible, and each team member focuses on a single user story at a time. The result of one piece flow is that the time between when the team first starts working on a user story and when they can ship it fully developed, tested, and documented is very short. The timeframe is generally on the order of a week at most and usually days.

In one piece flow, when development starts on a story, QA should be creating test cases for that story (story testing) at the same time. When development is done, QA should then automate the test cases and make sure they all pass. At the same time, the user documentation is written. One last step that must be completed prior to considering the story done is that all of the artifacts connected to that story such as source code changes, documentation updates, new test cases, etc must be integrated into the source code mainline.

Ideally, when following one piece flow, you would have done everything required to release the product to validate that the story really is done. That’s generally an impossible goal when just getting started with Agile, but it is a goal to keep in mind as you go. When working on stories, try to adhere to the principle of one piece flow to the greatest extent possible. As you read on you will find additional practices which simplify and reinforce the practice of one piece flow.

One last point. It may sound from the name that you can only work on one story at a time when following one piece flow. But really it means that for any story that is being worked on, it is progressing as fast as it possibly can without anybody that is working on it switching between multiple tasks. Another way to look at it is that the team should only be working on more than one story if the second story can be worked on without affecting the total time it will take to complete the first story. Likewise, the team should only be working on three stories if it won’t affect the total time it will take to complete the first two stories on an individual basis, and so on. A good rule of thumb is to only be working on as many stories simultaneously as you have developers on the team.