Single Piece Flow in Scrum Teams

September 19, 2011 at 2:06 pm 3 comments

Here is an easy to apply tip to improve your velocity: Focus on the User Story with the highest priority using Single Piece Flow (aka One Piece Flow) on a team level.

How it works
Single piece flow means that the whole team works at one User Story at any given point in time. Only when the whole User Story is done the team moves to the next User Story.

Why it
Single Piece Flow works due to several positive effects:

  1. Single Piece Flow forces the whole team to cooperate continuously.
  2. This ensures that every team member is informed about state and progress of each User Story. Furthermore the team members learn from each other through intense cooperation.
  3. On this basis it is easy for team members to help each other.
  4. Point 3 together with the fact that a team generally is faster in implementing a User Story leads to a shorter lead time of the User Story.
  5. Shorter lead time and reduced Work-in-Progress means for the team that it has to remember only few things for a short period of time. And this fact reduces the number of bugs and decreases the time needed for bug fixing.

You may doubt what I wrote. Perhaps Single Piece Flow reduces the lead time per User Story. But does it enhance overall throughput or does it lead to under utilization of the team members and higher costs?
Maybe… Luckily it is easy to check. Just try it for one Sprint and then inspect&adapt. You are welcome to share your findings in the comments of this blog article.

Entry filed under: it-agile-blog-planet. Tags: .

S.O.L.I.D. for dynamic and functional languages at SoCraTes 2011 Vom Entwickler zum Berater und glücklich dabei

3 Comments Add your own

  • 1. Stefan Lieser  |  September 19, 2011 at 3:14 pm

    Under utilization is not a problem if it happens on people not working on the bottleneck. That’s because the whole team can’t output more or faster or better than its bottleneck. See theory of constraints.

  • 2. Florian Eisenberg  |  September 22, 2011 at 8:11 am

    I’d say that it really depends on the size of your stories. If you have really, really small stories where it’s just “not feasible” to have a team of seven working on it, you might want to try SPF with subsets of your team (which obviously need to be somewhat crossfunctional themselves).
    On the other hand, if under utilization does happen on pure SPF, then team members not working on the current story are free to work with the PO, SM, infrastructure improvement, preparing the next story etc.
    So, generally, I do agree with you. Limiting the WIP should give you a lower lead/cycle time for stories. Which, in turn, is a good thing in terms of risk management.

  • 3. stefanroock  |  September 22, 2011 at 9:33 am

    I have Done SOF with a team of six people with Story sizes < 2h (for the six). Therefore I propose to not speculate on this but just try it. Inspect & Adapt!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed

%d bloggers like this: