So, my current project uses story points to track developer productivity. This is good (it’s better than some other metrics, like lines-of-code-per-week or something), and bad. For example, I just completed about one week’s worth of story points in about 3 hours. There are a few potential reasons for this:

• Story point inflation: over time the numbers might get bigger
• The initial estimate was overly large
• Developer productivity: Maybe I’m getting better as a developer, or better on this project
• People left me alone and didn’t talk to me for those 3 hours
• Maybe I just got in the zone for 3 hours and just cranked code like a madman, got in the flow, and struck productivity like you might strike gold in the Old West (once, and not hit it again for a while)

So, while story points are good as an estimating tool, you can’t really use them to measure programmer productivity:

1. 2 of the reasons I listed above question the validity of the initial story point value
2. 1 of the reasons involve me locking myself into a cube and not talking with anyone, which might be unobtainable in your environment (it is in mine, at least during business hours).
3. 1 of them involves professional growth of developers, something you can’t exactly predict or bank on (can you predict when your child is going to grow out of those new clothes?)
4. One of them involves something akin to striking it rich

What’s worse, and probably more frustrating to management trying to manage via the story point metric, is the complexity opposite: “I just completed 3 hours worth of story points in a week. FML.” Guess what? Take the exact opposite of my “reasons why I completed one week of story points in 3 hours” reasons… and those might be the reasons why I didn’t get story points done. Thoughts?