User Tools

Site Tools


how_do_we_control_work-in-progress_wip

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
how_do_we_control_work-in-progress_wip [2020/06/02 14:21] – external edit 127.0.0.1how_do_we_control_work-in-progress_wip [2020/06/10 12:50] (current) – ↷ Links adapted because of a move operation hans
Line 21: Line 21:
   * Establish a cadence and synchronize work on that cadence. Done correctly the cadence will naturally mean that you cannot take on too much work (although note that people / teams will still over-commit.)   * Establish a cadence and synchronize work on that cadence. Done correctly the cadence will naturally mean that you cannot take on too much work (although note that people / teams will still over-commit.)
   * As it is visible, set limits on how much WIP you are willing to take on for this stage. Note that setting a WIP to be the "same as the number of people in the team" just hides the problem - you need to set up a lower constraint so that people really start concentrating on flow.   * As it is visible, set limits on how much WIP you are willing to take on for this stage. Note that setting a WIP to be the "same as the number of people in the team" just hides the problem - you need to set up a lower constraint so that people really start concentrating on flow.
-  * Aggressively triage the work. See [[blog:how_do_we_deal_with_product_backlog_explosion|How Do We Deal With Product Backlog Explosion?]] for ideas on how to apply this thinking to a product backlog, but the reality is that this idea can be applied everywhere.+  * Aggressively triage the work. See [[how_do_we_deal_with_product_backlog_explosion|How Do We Deal With Product Backlog Explosion?]] for ideas on how to apply this thinking to a product backlog, but the reality is that this idea can be applied everywhere.
   * Ruthlessly prioritize at all levels. Too much WIP at the program level has a tendency to result in too much WIP at the team level.   * Ruthlessly prioritize at all levels. Too much WIP at the program level has a tendency to result in too much WIP at the team level.
   * Only commit when it means something. For example, if you are about to start some work, but have a dependency on another who is not able to do their part for a long time, it makes no sense to start your work now.   * Only commit when it means something. For example, if you are about to start some work, but have a dependency on another who is not able to do their part for a long time, it makes no sense to start your work now.
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/how_do_we_control_work-in-progress_wip.txt · Last modified: 2020/06/10 12:50 by hans