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?

3 Answers 3


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.

  • and of course my product owner said I should of course try to read the sprint goal and do the stuff... well I am working in a big non-IT company where scrum isnt taken seriously...
    – Pascal
    Commented Feb 12, 2016 at 19:02
  • The product owner is always going to want to say that. However, it's not in the product owner's purview to dictate capacity. The team dictates capacity. I'll edit in some text about this above as this does bring up some good points that I didn't articulate. Commented Feb 13, 2016 at 1:12
  • It's useful to notify the product owner of any at-risk stories as soon as possible, so they can adjust as necessary. The product owner should understand that it is far better to find out a story is probably not going to be completed two days into the sprint than in the sprint review many days later. It also reinforces trust to be upfront about the bad news. The typical alternative to not being upfront is a product owner (and other stakeholders) that gets blind-sided by a "final" sprint that grows into several "final" sprints and/or a release of a product that falls over in production. Commented Feb 13, 2016 at 1:33

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.


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

  • 1
    No Estimates is definitely a hard sell. Even to those of us who think it might be a better way to work. Might be.
    – RubberDuck
    Commented Feb 9, 2016 at 0:01
  • Of course it's a hard sell. Without estimates, you'll ALWAYS choose the tasks with the highest value, even if they're going to take a disproportionately long time. That's insane business.
    – pdr
    Commented Feb 9, 2016 at 14:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.