Single Piece Flow in Scrum Teams
September 19, 2011 at 2:06 nachmittags 3 Kommentare
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:
- Single Piece Flow forces the whole team to cooperate continuously.
- 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.
- On this basis it is easy for team members to help each other.
- 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.
- 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.
Really?
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: Scrum.
3 Kommentare Add your own
Kommentar verfassen
Trackback this post | Subscribe to the comments via RSS Feed
1.
Stefan Lieser | September 19, 2011 um 3:14 nachmittags
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 um 8:11 vormittags
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 um 9:33 vormittags
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!