The requirements for the system or product being developed by the project are listed in the Product Backlog. The Product Owner is responsible for the contents, prioritization, and availability of the Product Backlog. The Product Backlog is never complete, and the Product Backlog used in the project plan is merely an initial estimate of the requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves.
The Product Backlog is
- management constantly changes it to identify what the product needs to be appropriate
As long as a product exists, the Product Backlog also exists.
The complexity factor increases the estimate due to project characteristics that reduce the productivity of the Team. When the Product Backlog is first thought of and entered, its estimated work is placed into the column of the Sprint that is going on at that time. The developers and the ScrumMaster devised most of the backlog items shown before starting the project.
A burndown chart shows the amount of work remaining across time. The burndown chart is an excellent way of visualizing the correlation between the amount of work remaining at any point in time and the progress of the project Team(s) in reducing this work. The intersection of a trend line for work remaining and the horizontal axis indicates the most probable completion of work at that point in time. This allows the ScrumMaster to “what if” the project by adding and removing functionality from the release to get a more acceptable date or extend the date to include more functionality. The burndown chart is the collision of reality (work done and how fast it’s being done) with what
is planned, or hoped for.
The Sprint Backlog defines the work, or tasks, that a Team defines for turning the Product Backlog it selected for that Sprint into an increment of potentially shippable product functionality. The Team compiles an initial list of these tasks in the second part of the Sprint planning meeting. Tasks should be divided so that each takes roughly 4 to 16 hours to finish. Tasks longer than 4 to 16 hours are considered mere placeholders for tasks that haven’t yet been appropriately defined. Only the Team can change the Sprint Backlog.
The Sprint Backlog is a highly visible, real-time picture of the work that the Team plans to accomplish during the Sprint. Once a task is defined, the estimated number of hours remaining to complete the task is placed in the
intersection of the task and the Sprint day by the person working on the task.
Increment of Potentially Shippable Product Functionality
Scrum requires Teams to build an increment of product functionality every Sprint. This increment must be potentially shippable, because the Product Owner might choose to immediately implement the functionality. This requires that the increment consist of thoroughly tested, well-structured, and well-written code that has been built into an executable and that the user operation of the functionality is documented, either in Help files or in user documentation. This is the definition of a “Done” increment.
If the product increment that is created during the Sprint has a more exacting use, the development organization usually defines the additional product requirements as standards or conventions.