“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.

Our PO works through an example on the board (note remote team member on monitor)

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?

7 comments on ““Estimating” Meetings

  1. I’ve found that when breaking out new themes or epics we have a “Story Carding Meeting” where we spend time as a development team to break out the epics into more manageable chunks. So our process for these are:
    1. Discovery – Reviewing all the work
    2. Story Carding – Breaking down epics into stories
    3. Release Planning
    4. Sprint Planning

  2. Very good article.
    One question – how do you know actual effort per story – do you track it or based on gut feeling?

    One thing I suggest to teams is to look at estimated size compared to actual cycle time.

    Draw a control chart (spc) to highlight special cases and indeed retrospect on them.

    One other thing teams find helpful is maintaining an estimation board tracking history of estimated stories. Think kanban board where each lane is a size range and the cards are the estimated stories.
    Builds much better baseline and predictability over time

  3. Thanks for your comment, Yuval! We do track actual time spent on each task card, the ScrumMaster and PO do something with that information later. We do plan to do story retrospectives when the actual time is quite different from the estimated time, thanks. I’m intrigued by the estimation board tracking history also, maybe we’ll try that.

Leave a Reply

Your email address will not be published. Required fields are marked *


Recent Posts: