When contracting for Agile software development services, sometimes contracting officers make “story points” the thing that they’re buying. This is an enormous mistake, on a couple of levels, and nobody should ever do it.
Let’s talk about why.
First, let’s define “story points.” Agile development teams need to figure out what they’re going to work on at the start of every ~two-week sprint. Working with the product owner, they need to identify a bunch of user stories that will take as close as possible to two weeks.
One way to figure this out is for the team to figure out how many “story points” to assign to each story — basically, how much work it will be to get it done. That number might be labor hours, or it might represent how complex or uncertain the work is. There are all kinds of ways to come up with story points. Story points are a rough number, sometimes picking from a number in the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…) to make that clear.
The team might have learned that they have the capacity for e.g. 300 story points in a sprint, so they’ll pull in a total of about 300 story points of work. The team decides these numbers. They are only for the purpose of estimating how much they can do in a single sprint.
Contracting officers hate time and materials contracts. They want to contract for a firm, fixed price (FFP). When procuring Agile development services, they desperately look for something, anything, to FFP. (Hint: There is nothing.) So they sometimes settle on story points as a thing that they’ll buy for a fixed price per point.
The first problem with contracting for story points is that story points are imaginary. They are a tool used by the development team for the development team. They are sometimes externally indefensible, which is fine, as long as they work for the team!
The second problem with contracting for story points is that they are, basically, a fictional currency with a value invented by the vendor. You might as well be buying 1,200 flibberdigibbets, or 1.6 million dinglehoppers. The value means nothing, can change at any time, and cannot possibly be fixed within a contract. (If you’re thinking “you could fix them at one labor hour per story point,” then, congratulations, you have invented labor hour contracts, which is precisely what contracting officers are trying to avoid by using FFP contracts.)
In short, if a contracting officer knows anything about about a vendor’s story points, something has gone terrifically wrong.
For more about the proper methods of procuring and overseeing Agile development services, see “Oversee Agile projects by measuring end user outcomes instead of requiring project teams to perform tasks by specific dates,” in 18F’s Federal Field Guide.
Comments are closed.