If you remove buzzwords though it makes more sense: 1) It is impossible to have specs for a complete project at the beginning. So let's ship piece by piece and

If you remove buzzwords though it makes more sense: 1) It is impossible to have specs for a complete project at the beginning. So let's ship piece by piece and accommodate spec changes as they are discovered. 2) We need at least some visibility on what to do so let's bundle a few short tasks for the (literally) foreseeable future. 3) Since we can't estimate task duration precisely because nobody ever managed to do it, let's find some measure on how much work we can get done. 4) How do we estimate this: empirically by progressive approximation. 5) This is not actually necessary. Also I think that one of the more interesting parts of the planning poker is discussing the why a task may or may not take a long time. It can give insight into system complexity to people less familiar with a specific part of the project. I must say though that the goal completion was more of a unicorn where I worked. We always had sprints overspill to the next one but that was not necessarily an issue. If there is one thing I dislike about the scrum it is the rigidity which is often introduced. I think a laid back approach to it makes it more useful.