Story points for the misinformed.

Last week, I wrote a harsh critique of how project estimation is done at many organizations.  I don't particularly appreciate using the words farce and tragedy lightly, but in my experience, many projects devolve into these realms.  This week, I want to talk about story points and how they solve some of the problems I discussed how estimation is broken.

I have written two essential blog posts on story points.  The first was my reappraisal of story points as measurements of difficulty and ambiguity.  The other blog post illustrated how story points could be used to meet deadlines.  After reviewing those blogs, I think they clearly explain the advanced uses of story points.  For those new story points, this blog is for you.

Last week, I said that traditional forms of project management rest on the mistaken notion that time and money are equal.  It means when a project manager or developer gives an estimate, and the executive treats it like a quotation of work.  The experience is similar to going to an automotive mechanic, receiving an estimate for $300 of work, and getting a bill for $3,000.  As a consumer, you were expecting and budgeting for a $300 bill.  When confronted with an invoice ten times larger than expected, a person usually falls into a rage spiral.

Story points defeat this situation.  First, the team members play planning poker and collectively decide how many points it takes to complete a unit of work.  It is not the opinion of one person but a consensus of numerous technical professionals.  Next, story points are the sum of ambiguity and difficulty of a unit of work.  There is no meaningful way to convert a story point into money or a measure of time.  The only thing that is certain is a team can complete a specific number of story points in a sprint time box.  Velocity is the average number of story points completed over at least three sprints.  As I illustrated in an earlier blog, velocity allows executives, scrum masters, and developers a means to forecast deadlines.  Finally, story points allow for severe discussions about scope, resources, and time without having to discuss dollars and cents.

My colleague Steve Sether points out that story points are not a silver bullet for poorly managed projects.  Story points can be inflated to create the illusion of increasing velocity. Accountants attempt to put a dollar figure to story points and executives often ignore them to make promises without consulting the development teams.

Tell an executive that we have 213 story points in a software backlog is much more informative than claiming that we can hit an arbitrary deadline.  We can act and make more informed decisions rather than rely on gut instincts.  Project estimation should not be farce or tragedy; with story points, a development team and a scrum master have a better way of estimating work and delivering it to the business.

Until next time.