January 17, 2022
“So, is this just a way of counting story points? Issues? How are you tracking time? There’s absolutely no way my team will submit time cards, so I presume we can’t get any value from Allocation?”
Here at Jellyfish, when it comes to Allocation, we’ve heard it all.
Despite the rise of Allocation – a way of measuring the distribution of software engineering team’s work across a number of axes – there’s still confusion as to how it’s derived, and why this metric can represent incredible value for data-driven engineering teams.
It’s understandable; Allocation can be complex in that it is often calculated from data spanning across multiple tools, workflows and structures.
Rather than delve into the how of calculating this metric – something we detailed in our What is Allocation? blog – today, I want to delve into the why. To achieve this, I’ll be examining what Allocation most certainly is NOT and, in the process, illustrating why this metric should be a welcome addition to the arsenal of any engineering leader.
It’s NOT Counting Story Points
In the past, we’ve made the case for not counting story points, but let’s face it; If there were a better alternative, dev teams would’ve switched over faster than you can say ‘agile’. They’ve been a mainstay for a reason.
Story points are a great planning tool, and in specific scenarios, measuring them can be advantageous (we offer story point analytics in a number of places within our Engineering Management Platform). Challenges arise when you expand the scope of story points beyond their intended use. Story points are a representation of the expected effort that a task will take for a software engineer to complete; they’re estimates. The very nature of software development means that the effort a story point represents will differ across teams, managers and projects. Trying to extrapolate actual effort across teams utilizing story points without this context provides weak insight when trying to grapple with an org-level understanding of engineering.
That’s why Allocation omits Story Points altogether; rather, it’s a calculation of engineering signals like Jira issue progression or Github commits. By deriving Allocation from standardized data, and using time (a concept that translates across teams and business functions alike) as the representative unit, you strip away the ambiguity and discrepancies between how story points are calculated. Unlike story points, Allocations accurately reflect work scope completed, and do so in a way that is meaningful to everyone.
It’s NOT Calculated via Time Cards
At Jellyfish we’re often asked how Allocation can possibly provide an accurate representation of engineering effort without – try not to recoil – asking for time cards.
I don’t know about you, but I don’t know a single engineer (or engineering manager for that matter) who would take a job knowing they’d be expected to fill out time cards. What’s more, they shouldn’t! It’s not an efficient use of time, it erodes a culture of trust between ICs and Managers, and not a single employee enjoys doing it. Likewise, no serious vendor in the engineering management space is going to set the expectation that in order to get value from a metric, your engineers will need to manually fill out time cards.
I’ll go a step further. Similar to Story Points, time cards can be highly subjective. They’re an approximation, often completed as a last minute afterthought on a friday afternoon.
Time cards are never something we’d advise. The future of work is automated and to derive value from effort-driven metrics, the calculations involved also need to be automated.
Allocation is the aggregation of data generated from your existing engineering work flow. Signals pulled automatically from your issue tracker, source control tool, etc. This data is then normalized to create a model for how engineering time is being spent. The value here is that the picture painted is a far more accurate reflection of output in comparison to anything that can be collated via the likes of a time card or even a PMO (despite their best efforts). Allocation strips out the bias of manual collection,while maintaining the nuances of individual teams’ software engineering processes. Allocation is the most automated and accurate way to measure engineering effort, and thus the most trusted metric to inform strategic decision making.
It’s NOT just for Engineering
Story points, cycle time, sprints, issues and epics – all valid constructs born of [mostly agile] software development. But try telling the Board how that new game-changing feature is coming along by using completed story points; I guarantee it’ll be a non-starter.
Engineering is the most technically complex function of modern business. As such, the measurements we use to operate are bespoke to the unique challenges of engineering. But Engineering has quite quickly become the most important (and most expensive) pillar of many businesses. Engineering leaders no longer operate exclusively in the technical realm. They need to be able to contribute to the strategic goals of the business and that means communicating progress, roadblocks, expectations, and limitations – and here’s the challenge – in a way that resonates with business executives. How your engineering team communicates these concepts internally probably isn’t going to cut it.
Enter Allocation; a simple, yet meaningful representation of engineering investment against the strategic objectives of the business that neatly compiles complex, messy engineering signals and converts them into units of time – a concept that will resonate with even the most obtuse board member.
We like to think of Allocation as the engineering leader’s rosetta stone of cross-functional business communication. By adopting allocation as a metric, you’ll be able to interface with other executive team members much more effectively. In turn, these non-technical executives will develop a vested interest in ensuring you have all the resources you need to properly tackle strategic objectives so that they more broadly align with business strategy.
