Where in scrum methodology do you define the approach/concept for a certain task

Question

We have a sprint planning every sprint which takes 2 hours. In this little time we discuss 10 user stories, write them down and estimate them.

Very often after the estimation (during sprint) I realize that the estimation was bad because the technical solution takes more time as we did not really and exaustively talk about the problem. This puts always lots of pressure on me.

In this sprint planning I must also say we talk to much. It could be more focused.

In scrum is it really enough to plan the task for a user story in the sprint planning or should there be more meetings or other meetings for this task?

Answer 1

In general, you should have already looked at the stories and had an idea of an estimate or what obstacles might exist and need to be discussed prior to the planning meeting. This process is part of backlog grooming. This may or may not involve having a meeting about it. You should also be estimating beyond the current sprint, but you can revisit estimates in the planning meeting where the task will be added to the sprint if you've realized something since the story was last estimated.

If a story does turn out to be significantly under-estimated after being added to the sprint, you should bring that up clearly in your next stand-up meeting. It may be that someone else has capacity to help or to take other stories to give you more time. If no additional capacity exists, it may make sense to stop working on the story so that other stories aren't impacted (and usually, if something is significantly under-estimated, more communication is necessary anyway). [edit] Stack rank (and the team's understanding of business needs and task dependencies) should definitely be taken into account in deciding which stories might need to be dropped. Instead of dropping the mis-estimated story, it may make more sense to drop other stories to free up capacity. It's certainly valuable to get the product owner's input in making this trade-off, though it is the team that decides. This will, of course, mean that you "fail" the sprint. In the sprint retrospective, you should discuss why the story was under-estimated, how you could better estimate the story in the future, and whether and how to have capacity for mis-estimated stories.

What you shouldn't do is kill yourself trying to complete the story. This will lead to a misrepresentation of your team's velocity and capacity and encourage future under-estimates.

Answer 2

A common solution to this problem is to have a separate shorter story called a design spike. This is where one team member explores possible designs, perhaps trying a few manual proofs of concept, then documents the results and reports to the rest of the team. You allocate some time for this in the previous iteration.

The output of a design spike is generally a better estimate, along with better understanding of your risks and dependencies. Usually the time you spend on a design spike is saved on your main story, often more.

The basic idea is that someone on your team should have spent a sufficient amount of time thinking about the problem before planning, so they can just be the expert and summarize for the rest of the team. You're never going to be able to effectively explore a brand new problem over the course of a meeting. One way or another, you need to find time to explore the problem before the planning meeting. If a design spike doesn't work for your team, use your retrospectives to evaluate and adjust.

Answer 3

If I may, I'll turn this question on its head: how far into a task do you realise the estimate was wrong?

Let's take an example: I estimate a story will take me three days. Two days into it, I realise it's likely to take six days.

So ask yourself, if it took me 16 hours to work out it's a six day task, how long would it take the team to work this out when discussing, rather than implementing, it? Ignore the "mythical man-month" problem and let's assume a team of four could work it out in four hours.

If you spent four hours on each story, that would require a 40 hour meeting to arrive at a reliable estimate!

Clearly, I'm playing with numbers here, but the whole point is that estimating is another word for "guessing". You have to compromise between not wasting time on details and ending up with poor estimates. A common solution to this is to examine the real times versus estimates in the retrospective and to either learn from this and adjust your estimates upwards as a result, or to apply a "fudge factor" to the estimates to get a possibly more accurate indicator of the likely time. The other option (which is a seriously difficult hard-sell) is to adopt the "no estimates" approach...