Plan the release and sprint
Although the Product Backlog is the container for all not-yet-planned stories, explicit planning activity takes place to decide which stories go into a release or an iteration. This is particularly useful for larger teams with many stakeholders; everyone may be allowed to fill stories into the Product Backlog, and the product owner can decide which of these items are added to the release.
When you create a project area by using the new Scrum Process template, plans are automatically created for the release and the first two sprints. You might recall that, earlier, we adjusted the release timeline dates right after creating the project area.
During release planning, items are pulled from the Product Backlog into the release. According to the ranking provided by the product owner based on product research, as many stories can be pulled into the release as can be accomplished in the scheduled time frame (based on the team's velocity). The release plan can easily be revised later, and items can be moved back to the Product Backlog. In return, other items can be pulled into the release based on stakeholder feedback.
- If the Product Backlog plan is not opened yet, open it now.
- Select all but the last two stories.
- After selecting the 18th check box, move the mouse cursor to the right and select Modify, and then plan all selected items for Release 1.0 (see Figure 32).
- Changes are saved immediately, and all moved items are shown as inactive (gray).
- Refresh the plan to show only the remaining two items.
Figure 32. Plan items for the release
- Open the Release Backlog plan.
- If items are not already shown, refresh the plan.
In case you want to move items that have children (sub-items), make sure to select and move the children, as well. Otherwise, only the selected parent items are moved into the release.
The advantage of the Release Backlog is that you can maintain only those items in the plan that will actually go into the release. The release burndown chart (discussed later in this article) reflects items that are moved in and out, which allows you to precisely monitor whether the release goal can be met.
Iteration planning starts with pulling as many stories from the Release Backlog into the sprint as the team can commit to. The second step is to develop the tasks for each of the stories that the team needs to complete. Although the result of sprint planning is a collection of estimated tasks, which are most likely assigned to various team members, it is important to remember that the purpose of sprint planning is for the team to commit to completing a collection of stories, thereby adding new and deliverable functionality to the product. The planning and estimating helps the team decide how much work will fit into the sprint.
- Open the Sprint Backlog plan for Sprint 1.
- Select the Overview tab.
- On the Overview page, click Edit Page and document the sprint goal (see Figure 33.
Figure 33. Documenting the sprint goal
- Click Save.
- Assign stories to the sprint
From the Release Backlog, select the relevant stories, and plan them for Sprint 1. Proceed the same way as described under "Fill the Release Backlog" previously for release planning (see Figure 32).
- As an alternative, in the Iterations view of the Release Backlog, drag the stories from the release to an iteration (Figure 34).
Figure 34. Assigning stories to the iteration
This will assign the stories to the Sprint Backlog. Changes are applied immediately. (In Rational Team Concert V1, the stories actually moved from the Product Backlog to the Sprint Backlog, but in Rational Team Concert 2.0, they remain visible in the Product Backlog for easier tracking. In V2.0, you use the Iterations view to monitor which iterations the stories are assigned to.)
Figures 35 and 36 show the results.
Figure 35. Stories assigned to an iteration (release backlog)
Figure 36. Stories assigned to an iteration (Sprint Backlog)
You might need to refresh the Sprint Backlog to see the newly planned stories.
The next step is to break down the stories that have been added to the sprint. This means that tasks are created for every step that needs to be performed to get the story to "done" (that special scrum definition of "done," which means that the feature is truly finished and can be fielded, if necessary).
- Move the mouse cursor over the rectangle on the left of an item to bring up the action selection menu.
- Move the cursor to the right until you see the "Add Work Item Below," action label (Figure 37), and click that action.
Figure 37. Add tasks to a story
- Select Task.
- Enter the summary for the task.
Figure 38. Add a task
- Click Save and Close.
- A task will be created below the story. Notice that it is created at the same indentation level as the story.
If you do not see the newly created task in the plan, make sure that Execution items are not excluded from the plan (see Figure 39).
Figure 39. Filter menu
- Because this task "belongs" to the story, bring up the action menu for the task and select Demote to move it under the story. As an alternative, you can drag it onto the story, which also moves it "under" the story.
Figure 40. Demote the task
Make sure that you use a view where items are displayed in a tree mode. In case you selected a view where items are shown in a flat manner, you will not be able to indent tasks. The Work Breakdown view that is opened by default when a sprint plan is created shows items in a tree view.
In a typical Sprint Planning meeting, team members call out tasks that need to be done. Just getting them all recorded will be sufficient for now. Time estimates and assignments can come later in the meeting.
- Continue adding tasks for this and the other stories.
Because of the iterative and interactive nature of sprint planning, it might work best to do these steps for one story and then complete the steps below that to provide estimates and owners for the tasks. Then you can return to this section to plan the next story. There is no point in planning more work than there is time to do. Keep an eye on the Team Load indicators to know when to stop.
Now it's time to estimate the tasks that have been entered for your stories. You can follow these steps in the order that fits your team's practices:
- To enter estimates for your tasks, click on the task to open the Quick editor. Then enter the estimate. Do this for each task, one after the other.
Alternative: You can also enter estimates in the list by selecting from the drop-down menu. If your time estimate is not in the drop-down menu, choose More to get a small input screen where you can enter your estimate.
Figure 41. Entering time estimates
When you have entered all estimates, you can see the total estimates for each story, as well as for the whole sprint.
Typically, scrum team members sign up for tasks, and the assignments can be made at the same time. Because different team members may take different amounts of time to complete a task, you might prefer to finalize a time estimate after an assignment has been made.
- In the Sprint Backlog, from the list, drag tasks to the members assigned to the Havannah team. After assigning some tasks to team members, the Sprint plan might look as depicted in Figure 42.
Figure 42. Assign owner
The arrows at the left of an item indicate that these items are assigned to someone or somewhere else. Typically, tasks are assigned to team members, but the stories remain unassigned, and the team or the product owner decides when a story is finished. One advantage to this approach is that the breakdown of a story into tasks is always visible from this (and other) views that display both stories (top-level work items) and tasks (often not considered top-level work items).
Also, the workload is shown for every team member. Team workload can be monitored as tasks are estimated. To balance the workload and monitor progress, all team members must have entered their work assignments, as well as their scheduled absences.
Notice that Frank has no work hours and Rose has only 54 available work hours because of their limited availability or vacation days. You would continue estimating tasks until team members no longer have time available. For scrum teams to be successful, remember to leave some slack in everyone's workload to adjust for estimates that are inadequate or for interruptions. The intention is that all of the work committed is completed, no matter what comes up. So choose a percentage of slack that fits your team. To help assure success, leave more slack in the early stages; you can tighten it as you better understand the team's rhythm and capabilities.