I’ve been in a lot of debates at conferences and work about whether story points (which indicate the ‘size’ of any particular user story) should include effort, complexity, or both, so I’d like to throw in my two cents.
Basically, I think these debates miss the point of estimation entirely.
The first question is why bother using story points at all? Most teams use them to measure velocity, which is then used as a guide when deciding how much can be done in the next sprint, and (in some cases) how long a particular feature set will be in development before release. However, the Scrum Guide doesn’t really specify how to measure the items in the Product Backlog:
“Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.”
And as it turns out, experience has shown that velocity in story points correlates so closely with the number of stories completed in sprints that there’s no additional predictive power gained by using them. I.e., you can predict how many stories you’ll get done in a sprint by averaging the number of stories you’ve done in previous sprints. Story points have no value in that respect.
But (and this is a big but!), the estimation process itself has tremendous value. We’ll look at this caveat in the next post, Story Points Part II.