This content has moved permanently to:
https://blog.jonm.dev/posts/agile-architecture-kanban/
Friday, March 19, 2010
Subscribe to:
Post Comments (Atom)
skip to main |
skip to sidebar
The Art of Writing Software
All articles Copyright © 2007-2019 by Jon Moore. All rights reserved.
3 comments:
I enjoyed this. Thanks.
I want to know why the time increases as new items were added to the backlog. Did team members have to divert their attention to process new them in some way instead of working on current backlog items?
Is this why in traditional scrum the backlog is fixed during the sprint?
@Pythonic Avocado: actually, the time for us to do any one consulting "story" once we had started it was pretty constant. We imposed a work-in-progress (WIP) limit on ourselves, so we had to finish something before starting something new. The WIP limit plays conceptually the same role as a fixed sprint backlog in Scrum: preventing the team from getting overloaded.
However, from the point of view of our clients, there are only two times that matter: when they asked for something (i.e. when it hit our backlog) and when they got it (when we were done). They didn't care when we actually started working. Queuing theory basically says if things show up on the backlog faster than you can drain them, the backlog will grow longer and longer, and the "average wait time" for a client will also grow longer and longer. The only way to avoid this is either to drain the backlog faster (perhaps by hiring more architects) or to prevent the backlog from growing so fast (by sometimes telling someone "not now").
Post a Comment