There are two possible ways to use story points in Agile. One is toxic, demoralizing, and will probably drive your developers to look for employment elsewhere, while the other is mildly helpful, which is about all you can hope for from story points in Agile.
Can you tell which is which?
“This [story / issue / ticket / whatever] was estimated as only 2 points (about one day’s worth of work) but it took a whole week to complete!
“Why did it take so long?!”
“We estimated this [story / issue / ticket / whatever] as being 2 points (about one day’s worth of work) but it ended up taking an entire week.
“What did we miss in estimating that could have told us that this task was more than 2 points worth of work? How can we improve our process?”
Business and salespeople are optimists. Well, perhaps that’s painting with too broad a brush. Maybe it’s safer to say that, at the very least, their jobs require some degree of optimism regarding the raw probability of things like a sale closing or a business venture succeeding.
On the other hand, programming is an inherently realist (if not slightly pessimistic) endeavor. Well, maybe that’s painting with too broad a brush again and it’s safer to say that it should be a realist if not slightly pessimistic endeavor. (If you’re skeptical, just spend some time working on a behind-schedule software project and you’ll very quickly get in touch with your realist/pessimistic side.)
Continue reading “Optimism And Software Development”
99 story points in the sprint, 99 story points.
Take one down and try to write some code,
103 story points in the sprint.
Consistently-accurate estimates are the holy grail of agile project management. Or maybe they’re the Kool-Aid…