Based on the book, we should first estimate and then we should sub-task our stories.
I personally have some issues with that. I find, sometimes, that doing an estimation on a task where we (as a team) are not 100% sure what it involves is difficult, and results frequently in underestimation.
I've the feeling, that sub-tasking first before the estimation could help with that. As it will show exactly what it takes to full fill the task and even team members who don't know that part of the codebase could better estimate it.
I've been told, that this could lead to blowing up stories, as it is not time boxed at the time of sub-tasking. But I think, if the product owner is clear with the acceptance criteria, this shouldn't be an issue and would rather produce a more honestest estimation.
What do you think?
Latest comments (1)
Edit: sorry for the long post, there's a tl;dr at the bottom.
I believe that teams that estimate user stories and never revisit those estimations would be better off not estimating because they are reaping few of estimation's benefits.
Estimating before investing a serious effort in discussing design and technical details and dividing a story into tasks provides at least two business benefits:
Estimating user stories without going into much detail is cheaper, therefore more items in the backlog can be estimated and product people can give better predictions to stakeholders on when certain features will be delivered.
Estimating user stories can help with priorities. If two user stories deliver similar value but one is a magnitude of order more difficult to accomplish, it may be worth in some occasions to shoot for the easiest story. Again, you need to be able to estimate several user stories without spending a considerable time on each for this to yield benefits.
Back to my first paragraph, if your team never reviews estimates, you might want to stop doing it because it's unlikely that you're learning enough to adjust your estimates for them to be any useful. I've found that teams have a gut feeling for how many stories they can finish during an iteration and adding a few numbers to those stories doesn't make a big difference.
To your question: would it make more sense to estimate user stories after dividing them into tasks? As I said, I think it's beneficial to estimate stories before, but of course after spending some time discussing the details of a user story and splitting it into tasks, you should review whether the original estimate still holds or not and act accordingly.
In my experience, if you want to make estimations useful, there are a few things you should do:
Review your estimates at the end of the iteration: which stories did the team estimate accurately and which didn't? Why was that? Could we have done anything to estimate better the stories that turned out very different than we expected? Given the information we have now, would we estimate similar stories more accurately in the future? (you don't need to do this at the end of every iteration, but do it often enough so that you can learn when you're estimating wrong and can make sure you don't make the same mistakes in the future)
Compare new stories to previous work: it helps to build a catalogue of archetypical stories that you can use as reference for new work. You can classify them according to complexity (this is what we consider a 1-point story, this is a 2-points story, and so on), areas (this are stories that require work on the database, most of them are between 3 and 5 points; those are related to that particular area of the code, many are between 1 and 5 points; those are stories where we had to tinker with timezones, they are all 30+ points), or whatever classification helps you. The point is to have some reference that you can use to compare against new stories. Empirical data always trumps guessing.
Update estimates when you have new information: as I've said before, estimates shouldn't be a static thing, if you learn new information after having estimated a story, for instance by splitting it into tasks, that warrants a change in the estimate, you should do it.
TL;DR I suggest you keep estimating before dividing user stories into tasks and review whether the estimation still holds after the splitting. However, if you're not doing anything to ensure you learn from previous estimations to improve your accuracy, you might want to consider dropping estimates altogether.