« Lifecycle Variables | Main | Agile Organizations »

January 27, 2009

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834527c1469e2010536fa975b970c

Listed below are links to weblogs that reference Batch Size and Velocity Fluctuations:

Comments

Interesting post Mike. I've grappled with this problem as well: how to maintain some sense of velocity rhythm given work like bugs, change requests, new learning activities? I think the approach to maintaining a velocity rhythm lies in assigning the appropriate priority and estimates to all of the work to be undertaken: modeling, bugs, change requests (if treated separately from "stories" - as is often the case in a trad env) with increased estimates for the work (models, bugs, change requests, stories etc) that will likely require significant new learning (could view work with significant up-front learning as spikes with points for increased complexity). So, the number of stories or features done per iteration will vary, but the amount of work per iteration (points or whatever the preferred measure)is somewhat consistent.

Hi Luke,

Thanks for your feedback, I agree that you want to track (via points or whatever) all kinds of work to better monitor progress internally, even if external business feature based completeness does not seem to be moving that quickly.

I did not go into in my post because it is a little complex, but we actually have two sets of points: developer points and vendor points. Our vendor points are business functionality based, these are what I report on externally and what frequently slow down as changes, bug fixes and learnings occur. They are largely fixed, if a new high priority change request comes through we trade off business priority within our limited total capacity for the project.

However, our developer points are for internal consumption and are created for every bug and change we undertake. Tracking developer points we can see what we are busy on and estimate the work for an iteration, even when we do not get many vendor points done.

This is not my preferred approach, I inherited the project part way through and think the switch to a new consolidated metric would not be worth the disruption right now. I would prefer to see a single, transparent estimated backlog of features with bugs and change requests prioritized amongst the functionality.

Anyway, thanks again for your comment, I believe you are right and that creating estimates for the additional work really helps illustrate a more consistent velocity. As for whether it allows you to more accurately predict final completion time or not, I think is a different matter. That would assume a consistent percentage of work dedicated to changes and the like throughout the project which (in our case) is hard to predict.

Best regards
Mike

The comments to this entry are closed.

AddThis Social Bookmark Button

Your email address:


Powered by FeedBlitz

Tracker

  • Google Analytics
Blog powered by Typepad
Member since 07/2006

November 2014

Sun Mon Tue Wed Thu Fri Sat
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30