Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

work-in-progress build up is only a problem if you're not meeting deadlines.


No, it's a problem for throughput even if you don't have deadlines. Limiting work in progress is possibly the heart of agile.


In my experience, throughput is never constant... how do you know where is the limit?


There are fluctuations to be sure, but I think you can compare against estimates under two different methodologies and see whether you seem to perform better under one or another. (Of course you have to weigh the benefit of such measurements against the costs of making those estimates).

To my mind the costs of context switching are pretty well established at this point and the value of limiting work in progress is clear enough from experience, but that's just my experience and maybe you disagree.


I don't disagree with the cost of context switch and I see value in limiting the work in progress, my argument is against focusing on throughput and measuring it by units of work, and particularly using estimates as the base of the measure


> my argument is against focusing on throughput and measuring it by units of work, and particularly using estimates as the base of the measure

That's not what I'm advocating. All I meant to say is that when you have a lot of work in progress you get less done, whether or not you have deadlines.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: