Form based estimation
When your project is in flight though, your team needs as few interruptions as possible. People want to do deep work, in a state of flow. Long estimation meetings are the last thing you want at this stage. It’s also a reality that some projects need to report how much scope (in story points) they’re delivering in each sprint. Not only is this a measure of throughput, but it also helps:
track where the team is with respect to delivering the initial scope.
and forecast if the team needs to negotiate the scope of the upcoming release, based on what they know of their velocity right now.
These are perfectly legitimate needs from teams, clients, and stakeholders. To answer these, agile teams estimate every story threadbare during standalone estimation sessions or long, sprint planning meetings. A better way is possible. Remember the idea is not to be precise at the story level, but to be accurate at the project level. So, you shouldn’t fuss with minor estimation errors, because over the lifetime of a release errors will cancel out each other. I suggest going back to basics with the wideband Delphi method.
Back in the day when agile still wasn’t a thing, wideband Delphi estimation involved anonymously filling out forms. You can do the same thing now, but more efficiently with online forms. Let’s say you have a list of 10 user stories up for estimation. Here’s how you can go about things.
Create a form with two fields per row. On one field you have the name of the user story. In another field you have a drop-down list for developers to choose their estimate. This drop-down should have the Fibonacci numbers. You can add an optional text field so developers can explain the rationale behind their estimates.
Link the name of each user story to its description on your task board. That way if a developer needs to see the details they know where to look.
Send the form to a few developers and request them to estimate the stories. Give them enough time to respond, otherwise there’s no point doing this asynchronously.
Once all developers have responded, then average out all the estimates to derive the estimate for each story.
Only if estimates for specific stories vary quite wildly between developers, do you need a meeting to discuss differing points of view. In general, if the product owner describes stories clearly and the stories are small, you can reduce the chances of variation.
Be sure to include links to reference stories so your developers know what a 1, 3 and 5 pointer look like. They can use these reference stories to relatively size the stories on hand.
This asynchronous approach will not just save you time, but it’ll also leave a record of your decision-making process for you. By limiting your meetings only to resolve wide differences of opinion, you’ll also ensure that you don’t interrupt your team if it’s not necessary.