When to estimate?

Question

Our process in regards to estimates hasn't been as good as it should. We haven't been estimating issues prior to sprint planning, but rather groom the commitment before starting the sprint after sprint planning and estimates have been put in place.

This now has to change. My question is - when do yo estimate?

A bit more about our situation before continuing. The Product Owner and development department are on different sides of the world. Business analysts bridge the gap between the two. We are recreating an entire system, so sometimes developers are working on a new component for 6 months (while delivering on the way), sometime on a user story that takes 2 hours.

The 6 months components start with workshops with end-users > Sketches are drawn and discussed > Sketches are approved > Epic is created > User stories are created > User stories are specified > User stories are broken down and estiamted > User stories are implemented.

Question is, with upfront estimation on the user stories, with the "needed uncertainty because all issues should be considered with the same 'lack of information'", when should we estimate the user stories for the bigger components compared to the smaller user stories that come from the end-users of the rest of the system?

When they are created by BA's but before they are specified more? Just specify the epic when it is created? Other?

Ivar · Answer

Hi Kim, and yes - you are correct. We do not have a Definition of Ready in place. That is some of the things I am looking for with this question I guess.

In regards to the stories - we do not have user stories lasting 6 months. Our user stories are between 0.5 - 8 story points in total. And we are usually committing to 750-800 story points per sprint (3 weeks) for a 7 developer-team.

And yes - user stories are of course broken down and estimated during sprint planning (e.g. we know what we are dealing with once it is complete).

I'll chew on the other information in your answer :)

Kim Poulsen · Answer

As we are speaking Agile here I would say it is a matter of preference when you do it. However one thing is sure: Sprint planning is never completed without estimated issues as one of the outputs.

I suspect you don't have a Definition of Ready for your User Stories (US) specifying how your process around getting US ready for planning.

This is how we do it:

Every week we set aside time for refining the backlog (grooming). We run three week sprints. This time is divided in to focus areas: 1st grooming is figuring out which questions needs answers inside and outside the team for grooming to complete. 2nd session is focused on working in the gathered answers and asking for more information on those still needing it. 3rd grooming is focused on getting the issues at the top of the backlog either ready or moved out of the way in case we cannot get the information we need.

The grooming includes estimates. We have issues which are reestimated several times as information emerges but at least we have a pretty good idea of the total size of the active part of the backlog at any point in time.

User Stories lasting 6 months are also not really User Stories, they must be at least Epics as they span several Sprints. Divide them down to smaller parts and estimate each sub part.

So my point is: Estimate early, estimate often (as new information emerges), use planning poker to get better estimates.

Estimate the Epics in terms of business value if you BAs in the loop. Otherwise use relative sizing (XS, S, M, L, XL, XXL, animal sizes etc.)