“Estimating” Meetings

We’re a Scrum team (though in reality, we’re also doing XP along with some Lean and Kanban practices and principles). So, on occasion we have Estimating Meetings. Common wisdom in the Scrum world (at least as far as I’ve been taught) is that teams should not spend a huge amount of time discussing each story before estimating. Get an idea what the story is, and estimate it quickly; there’s a point of diminishing returns where spending a lot more time talking does not make the estimate more accurate.

Our team always ends up in long discussions, especially if our product owner has presented a brand new theme. Our ScrumMaster used to try to keep us on track using an egg timer and the like. We couldn’t break the habit, though. Yet, our estimating meetings seem valuable the way we do them. We don’t have them often, and our discussions save time later.

We’ve gotten into a pattern for estimating new themes. Our product owner schedules at least two meetings for a new theme: one for talking about the new functionality, which we call a “brainstorming” meeting, and one for writing and estimating the stories. For complex themes, we might have more than one “brainstorming” meeting. However, they are time boxed to an hour each. This gives us a chance in between meetings to think about the new functionality, how it might be modeled, talk amongst ourselves about it. Often, someone comes up with a brilliant idea in the second meeting that will save a lot of time in implementing the new features. It also helps us slice and dice the stories into appropriate size and priority.

In today’s brainstorming meeting, we talked about a new theme, to collect custodial fees from 401(k) participants. A custodial fee is a tiny percentage (for example, .05%) that our clearinghouse charges us for servicing the trades for our 401(k) participants. Up to now, we’ve notified participants that they’ll be charged this fee, but we’ve never taken it; we just pay the fee ourselves. We have enough assets under management today that it’s worth the trouble to collect the fee.

An Example

Today’s meeting ran long, but it was productive. These fees are similar to other fees, and if we come up with a better way to collect and process them, we can use the same model elsewhere. The programmers thought about some problems that currently can occur in production, and ways we might proactively prevent them with this new code.We decided to discuss this just within our development team tomorrow, then have an estimating meeting on Friday to write the stories and estimate them.

A Related Issue

Our product owner also raised an interesting issue. In the past several sprints, our velocity has been almost twice what it was in the previous few years. At the same time, he feels our estimates for stories have been much higher. Does our velocity look higher because we’re over-estimating? Or are we just getting more efficient and able to do more work each sprint? We discussed the reasons our velocity is higher, and what we can try to make sure our estimates are as consistent as possible so that the business can estimate ROI for potential stories and plan when features might be ready to release. We decided to start doing retrospectives when we complete a story that either takes us much longer than estimated, or much less.

Is This A Good Idea?

Are we doing estimating meetings “wrong”? I don’t think so. I think we have found a pattern that works for our team. Discuss, ruminate, discuss some more, estimate. It’s not BDUF, it’s usually just enough. When we don’t do this, we go with higher estimates because of the uncertainty – which is what we think may have happened lately (our PO has been so busy, we haven’t had brainstorming meetings for months). When we do, it often pays off in finding simple solutions.

I’m not recommending talking stories to death before estimating. But see if some time working through examples and discussing potential production issues, effects on other parts of the system, and other concerns will help deliver good solutions in a more timely manner.

How Do You Do It?

Have you come up with good approaches to tackling new themes and providing useful estimates that help the business figure ROI and prioritize stories?