First of all we prepare a Product Backlog based on a prioritized list of tasks (User Story) to be fulfilled. The prioritizing criterion is Business Value that is the anticipated profit caused by task execution.
The next stage is Estimation of each task performed directly by developers who simultaneously find out other details required for this task execution. Estimation may influence task prioritizing made by the customer and this may cause re-arrangement of tasks according to new priorities.
After that we define Sprint terms, select tasks from the Product Backlog (in the top-down direction) and sum up their Estimation. Then we transfer those tasks into a document called Sprint Backlog (a list of items to be completed during the current sprint, taken from the product backlog) until the Estimation total is lower than the amount of tasks that the team can execute during the iteration. Our Sprint duration is 2 to 4 weeks, which is normally applied in practice.
Every morning, in the course of the current Sprint the team carries out a Standup Meeting to actualize Sprint Backlog, reveal and discuss the related problems. The Sprint being over, the team provides the customer with a stable release version of the application.
Prior to a new iteration the team analyzes the results of the previous Sprint and makes organizational corrections in the development process to adjust it for the current project. To prepare a new Sprint we delete the fulfilled tasks from the Product Backlog, add new tasks, adjust tasks priorities and Estimations, appoint terms and compose a User Story. After that the team continues its work within the framework of a new iteration.
Using Sprints has proven highly efficient. According to the statistics we have accumulated it allows to achieve the following results upon average:
* simplify project control and reduce the corresponding costs by 40%;
* increase developers’ performance by 15%;
* decrease the amount of defects by 25%;
* achieve systematic release of stable application versions.