I work at a science and technology company in a department that specialises in education online. I have about 10 developers in my team and we're all in on Agile. That's "Agile" with the capital 'A'. I have my own reckons about it, but that's a bigger discussion. My immediate brain cycles are occupied with a piece of work we're looking ahead to.
How big? #
Our head of department recently confirmed a new pipeline of work that took a new partnership into account. There are a few new epics for major pieces of work that need to be sized up. We're not asking for down-to-the-hour estimates; simply a rough "finger in the air" type of ballpark from which to infer how loaded up our team's capacity would be and what sorts of expectations to set. That's where things got interesting.
The two-page write-up my team members provided was scattered with two different estimates: both trying to straddle the relationship between time and complexity. We'd asked for "t-shirt" sizes and ended up with two, typically phrased like "the t-shirt size for this piece is an 'S' by the first measure, and 'XXL' by the product manager's measure".
Massive red flag.
A quote often misattributed to W. Edwards Deming says "If you can't measure it, you can't manage it" (Deming actually said it's wrong to suppose you can't manage what you don't measure). While I actually like having data to back up decisions around a course of action, in our case it should be obvious that you can't infer anything based on disparate measurement approaches. We need a shared, understood basis from which to quantify our project items. It reduces confusion, ensures a common framework of understanding, and sets realistic expecatations for those who rely on the outcomes for decision-making.
Here's what I'm doing to attack the problem. Simply, the task is to settle an agreed set of examples for benchmarking the complexity or likely effort required in a given piece of work. In order to land on that, I'm going through past epics and projects and putting these to the team as frames of reference for future estimations. I'm also going to reinforce messaging that explains that we're looking for estimates, not concrete timeframes. This last point is important as I don't want my team to feel that they're about to be committed on a deadline before being able to adequately scope out the work.
Metrics need to be actionable. As a manager, I want to ensure I'm not overloading my team and can also set reasonable expectations with my own managers. But in order to do that reliably, I need my team to be able to compare and evaluate their estimates so that they're equipped to contribute to their own pipeline management. Managing by numbers alone is a bad idea: you need to take a data informed management approach; not a data driven one. But before you even move to relying on decision-making through data, you need to be confident that the data you're working from is a real representation of the system.