Starting the Next Sprint
Following the Sprint Review, the Product Owner may update the Product Backlog with any new insight –adding new Items, removing obsolete ones, or revising existing ones. The Product Owner is responsible for ensuring that these changes are reflected in the Product Backlog. See Figure 9 for an example of the updated Product Backlog.
Priority | Item | Details (wiki URL) | Initial Size Estimate | New Estimates At Sprint | |||||
---|---|---|---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | |||||
1 | As a buyer, I want to place a book in a shopping cart (see UI sketches on wiki page) | … | 5 | 0 | 0 | 0 | |||
2 | As a buyer, I want to remove a book in a shopping cart | … | 2 | 0 | 0 | 0 | |||
3 | Improve transaction processing performance (see target performance metrics on wiki) | … | 13 | 13 | 0 | 0 | |||
4 | Investigate solutions for speeding up credit card validation (see target performance metrics on wiki) | … | 20 | 20 | 20 | 0 | |||
5 | Upgrade all servers to Apache 2.2.3 | … | 13 | 13 | 13 | 13 | |||
6 | Diagnose and fix the order processing script errors (bugzilla ID 14823) | … | 3 | 3 | 3 | 3 | |||
7 | As a shopper, I want to create and save a wish list | … | 40 | 40 | 40 | 40 | |||
8 | As a shopper, I want to to add or delete items on my wish list | … | 20 | 20 | 20 | 20 | |||
… | … | … | … | … | |||||
… | 537 | 580 | 570 | 500 |
There is no down time between Sprints – Teams normally go from a Sprint Retrospective one afternoon into the next Sprint Planning the following morning (or after the weekend).
One of the principles of agile development is “sustainable pace”, and only by working regular hours at a reasonable level can Teams continue this cycle indefinitely. Productivity grows over time through the evolution of the Team’s practices, and the removal of impediments to the Team’s productivity, not through overwork or the compromise of quality.
Sprints continue until the Product Owner decides the product is ready for release. The perfection vision of Scrum is that the product is potentially shippable at the end of each Sprint, which implies there is no wrap up work required, such as testing or documentation. The implication is that everything is completely finished every Sprint; that you could actually ship it or deploy it immediately after the Sprint Review. However, many organizations have weak development practices, tools and infrastructure and cannot achieve this perfection vision and so there will be the need for a “Release Sprint” to handle this remaining work. When a “Release Sprint” is needed, it is considered necessary evil and the organization’s job is to improve their practices so this is not needed anymore.