Now that we’re apparently Post-Agile these days, I’d like to take a moment to remember why we — as an industry — were so excited about Agile to begin with. In particular, I’d like to look at some of the practices of Agile, and how they came around in the first place. There was a lot of wisdom and value in the Agile practices, and I’d like to call out that wisdom and value explicitly, as well as acknowledge where the difficulties with these practices were.
Moreover (and most importantly!) I’d like to hear from you about your experiences with these particular practices.
The first topic I’d like to hit is “points” and “velocity”. There is/was a lot of confusion about points, their value, and how they’re to be used. Because of that, the concept of “velocity” is totally lost. So let’s go back to basics.
The Problem:
Development estimates are notoriously difficult, yet are mandatory for business planning. Although developers have a sense of the size of work, trying to nail down a specific amount of time regularly comes with a +/- 100% margin of error. Further, the very basis of Agile is structured around refactoring the development process itself (more on that later), but there is no clear productivity metric out there (SLOCs punish refactoring and reward copy/paste; “tasks accomplish” assume equal weighting per task, etc.).
This Solution:
Create an artificial/abstracted metric of work — a measurement of the estimate itself. By giving tasks point estimates, we can measure how much work can get accomplished based solely on estimates. The amount of estimates the team can accomplish in a fixed time period is called the team’s “velocity”. This velocity naturally fluctuates over time, both in response to the team’s changing sense of the value of a “point”, as well as the team’s changing productivity. And while human tendencies to find patterns and make norms will probably cause points to standardize to some amount of “real work”, there’s no additional value in trying to measure that “real work”: we already know how many points of estimate we can accomplish, and we know how much we’ve estimated our current tasks for, so we have a good sense of expected delivery dates.
Difficulties:
- Bootstrapping the system is tricky, since people need to be given a sense of what “a point” is worth, but equating a point to a time period ends up fixing the value of a point in people’s minds, thereby destroying the flexibility of the system — and that flexibility is the biggest value! So kicking off the first estimation session by explaining “eight points is a task that can be accomplished in one day” immediately undercuts the system.
- Granularity on the system is lacking, and an implied linearity is a bad model for development. Development is by nature non-linear: for example, very simple things may only take 15 minutes, but even moderately complex things might take half a day, and very complex things might involve hours of work, not to mention conversations and meetings that span weeks. Unfortunately, if an average task is 5 or 8 points, 1 point is an overestimate of a one-word change: eights 1s does not equal the same amount of effort as one 8, even at the abstract level of estimation.
- Trying to decide on a way to measure a team’s velocity is non-trivial. Do you use a rolling average? The last iteration’s velocity? Some number negotiated between the product owner and the development team? Without some kind of velocity measurement, the point system’s value vanishes, but a bad velocity measurement results in bad estimates for delivery dates and often in an over- or under-worked team.
What are your thoughts about using a point system? Was this assessment fair? Have you worked in places where it went well? Went badly?
Related posts:
