If you’re pushing ahead full throttle toward a project deadline and see your project buckling at the seams, what do you do? Keep going and pick up the pieces sometime after the deadline, or throttle back? If the latter, what does that look like?
That topic of throttling back came up in a recent discussion with our team’s product owner, and it quickly became clear there were two different perspectives among us: recalibrate our planned sprint velocity (reduce it) or recalibrate our planned story points (inflate them). As to why the latter option was under consideration, it’s useful to have a little background.
We are a relatively new (and for some members, young) team on a new project working since February at about 40 points per 4-week sprint toward a somewhat firm (but widely advertised) 6-month Initial Operational Capability (IOC) release date.
There’s been a healthy backlog of features planned for this initial release, and the customer’s emphasis in order to accomplish them has for the most part been function over form (with an upon-delivery desire for both, of course).
What’s more, us developers yielding to our own desire to deliver functionality quickly, we have not given the attention to our Definition of Done it deserves. While well intentioned and far from ignoring it, we have made some sacrifices in the areas of architecture & design, documentation (architecture, API, and inline), unit testing, and what we have recently dubbed a “premium user experience” (all of which I herein characterize as “form”).
(Another factor is the nature of iterative development. We don’t know or are directed to defer consideration of future requirements in the interest of achieving today’s requirements. But that’s a topic for another day.)
What do story points represent?
So back to the question at hand: Does this conflict between function and form mean we need to slow our velocity or inflate our story points? To achieve the desired function and form, the Inflate proponents see a need for more story points. The Velocity folks see a need for more work per story point. Which begs the question…what do story points represent?
Before I answer that, I’ll add—being a CMMI Maturity Level 5 organization—we also have a bit of process integrated into our workflow. Not detracting from its virtue, it does increase the amount of work required to complete a story. Importantly, however, I have found this process to be roughly proportional to the complexity of the task. And the same is true for form.
Frankly, as a developer, I find it easier when sizing a story to think only in terms of the story’s complexity: “How hard is it going to be to do this?” I am able to estimate my own technical capability and that of my teammates, to evaluate the technical challenges of and external constraints on the task, and so on.
Things get fuzzier, though, when simultaneously I try to consider form and process…short of just using a multiplier. But here’s the problem with multipliers: they don’t fit well with a Fibonacci sequence sizing paradigm. What’s more, if you’re applying the same multiplier to each story, why bother? If you’re not, is the multiplier you choose from story to story something other than arbitrary? Too much to think about!
Do away with the sizing complexity and focus on function complexity. There’s no need also to consider form and process; they come along in proportion.
With the clarity gained by focusing on function complexity without consideration for form and process, I’m a proponent of throttling back on velocity and an opponent of inflating story points. You need more time to ensure a “premium” developer and user experience? Take it. But keep the story points that measure function complexity the same, being sure to give form the attention it’s due.