To be able to estimate what can get done per sprint and how long the full project will take, it is necessary to estimate how long each user story will take. Because one of the major challenges in development is accurately predicting how long things will take to get done, agile uses relative estimation. Features are rated on a 1, 2 or 3 point scale. More precise estimation is more challenging and ends up less accurate. It is easy to compare things relatively on a scale of 3. And if something is particularly challenging that you don’t think it fits within the “3 point” bucket, it should be broken down into smaller features that can each fit into the respective buckets. There are a number of ways to handle feature estimation. It can be as simple as just talking about it or it can be slightly more complex using “planning poker”. It’s also important to determine the sprint velocity of the team working on the project. That is how many “points” the team can complete per sprint. This velocity is averaged over time. And in typical average time value – the more sprints you do, the estimates and velocity become more and more accurate. That is to say that in some sprints you may not hit your goal number and other sprints you may exceed it. Over the course of a standard project, this averages out.

Agile projects are broken down into small, consistent time intervals. These intervals are referred to as sprints. They can be as short as a few days and generally are no longer than 3 – 4 weeks. We typically work in 1 – 3 week sprints depending on the extent of the overall project. During a sprint there is a dedicated team that includes designers, developers and business people working together. Before each sprint, there is a sprint planning meeting (often combined with the sprint review meeting). This meeting determines what the goals are for that sprint. Based on the team velocity, a set of features are pulled from the top of the backlog. During the sprint, no features are added and the sprint goals don’t change. The only exception to this is if the team finishes a sprint early. Client communication is generally limited to the daily standup results, but some firms allow for an open dialog via a chatroom.

Source: http://agilehandbook.com/agile-handbook.pdf