Scrum introduces a few new artifacts. These are used throughout the Scrum process and are described in the following sections.
The requirements for the system or product being developed by the project(s) 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 dynamic; management constantly changes it to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, the Product Backlog also exists. An example of Product Backlog maintained on the Scrum Product Management tool, based in a spreadsheet, is shown in Figure 1-4.
This spreadsheet is the March 2003 Product Backlog for a project for developing the Scrum Project Management software. I was the Product Owner. The rows are the Product Backlog items, separated by Sprint and Release subheadings. For instance, all of the rows above Sprint 1 represent tasks that were worked on in that Sprint. The rows between the Sprint 1 and Sprint 2 subheadings were done in Sprint 2. Notice that the row Display Tree View Of Product Backlog, Releases, Sprints is duplicated in Sprint 1 and Sprint 2. This is because row 10 wasn’t completed in Sprint 1, so it was moved down to the Sprint 2 for completion. If I decided that it was lower priority after Sprint 1, I could have moved it even lower in the priority list.
The first four columns are the Product Backlog item name, the initial estimate, the complexity factor, and the adjusted estimate. The complexity factor increases the estimate due to project characteristics that reduce the productivity of the Team. The remaining columns represent the Sprints during which the Product Backlog is developed. 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 I devised most of the backlog items shown before starting this project. The sole exception is row 31 (Publish Facility For Entire Project, Publishing It As HTML Web Pages), which I didn’t think of until Sprint 3.
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. A burndown chart reflecting this is shown in Figure 1-5. This allows me 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 items in the Product Backlog for future Sprints are quite coarse- grained. I haven’t had the Team start work on these items, so I haven’t expended the time to analyze and more finely estimate them. Similarly, there are plenty more requirements for this product. They just haven’t been thought through. When I have the time or inclination to start development again, I’ll define more Product Backlog items. This is an example of the requirements for the product emerging. I can defer building an inventory of Product Backlog until I am ready to engage a Team to convert it to functionality.
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. An example Sprint Backlog is shown in Figure 1-6. The rows represent Sprint Backlog tasks; the columns represent the 30 days in 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.
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. For example, the Food and Drug Administration (FDA) approves all products that will be used in life-critical circumstances in healthcare settings. As part of the approval process, the FDA checks that the product requirements are adequate and complete and that the requirements can be directly traced to the product. For each increment of FDA life-critical products to be potentially shippable, these additional facets of the product must also be developed—so that each increment of the product is potentially ready for FDA approval.