Prioritising the backlog

The key point about priority-driven planning approaches like Scrum - common in fact to all agile processes - is that the set of tasks undertaken by the team are ordered by priority rather than by a pre-determined procedure. (Priority is usually assessed based on business benefit and risk.) This article focuses on this particular aspect of using Scrum with xProcess and it covers:

• Adding backlog items to specific Sprints
• Showing a Sprint in Burndown and Gantt charts, and finally
  
• Prioritising the backlog

Having created a Scrum project with resources and a set of backlog items (see the previous post in this series) our next step is to prioritise the backlog. Our starting point here is a project which has three Sprints defined and a number of backlog items that have been estimated for approximate size. For simplicity in this example I've created 26 backlog items (with single character names from 'a' to 'z') with sizes of between 1 and 5 "points" (points being nominal units of size corresponding approximately to an ideal day's work for the average worker - see earlier post for more about this topic). Here's a view of my project at this point (click on the image to make it larger).

For the backlog items to be scheduled they must be moved from the "Unscheduled Backlog" task to one of the Sprints. Maybe you have an idea at this stage about the most important tasks, or maybe you want to see how long they would all take given the current estimates and resources. In either case just select the backlog items in the task list and drag-and-drop them to the first sprint ("Sprint 01"). As you'll see in the screenshot, I've opened the Project Explorer pane to do this. It's a view that can be selected from the "Window" menu - or simply click on the project icon next to the project name on the "Tools" pane. Once the backlog items are in a Sprint you'll begin to see the forecast start and end dates for them. You can now hit the "Priorities" button on the Tools pane and begin to put them in priority order. First though let's look at the Gantt chart for "Sprint 01" having added backlog items 'a' to 'v' to it. Double-click on "Sprint 01" to see its details and click on the "Gantt Chart" button. You can view other charts for the Sprint in a similar way, for example by clicking on the "Burndown Chart" button. In the screenshot below you'll also see that I've put the task list in reverse End Date order (by clicking on the column heading) and on the Gantt chart I've scrolled down to show the tasks at the end of the Sprint.

The Gantt Chart shows the forecast start and end dates of the tasks based on resources and estimates so far defined. As time progresses and tasks are started, re-estimated, completed or changed this chart will also change of course - it gives us a view of the likely outcomes based on information currently available. The risk element of the estimates is shown by the 75/95% extensions on the Gantt bars (see "Why I use 3 estimates..." for a discussion of this feature). Given that the target end date for this Sprint is December 19th, we can see that 2 items ('n' and 'a') are in the red zone and not forecast to finish in time and several others are in the amber zone and at risk of not finishing. This would therefore prompt review with the team and the client to whom commitments are being made so that expectations are set appropriately.

Now what if 'n' and 'a' are actually the most important items to get done in this Sprint, or what if there are dependencies between some of the tasks? How are these handled? Well dependencies can be added simply by dragging-and-dropping a task on the task it is dependent on. But it's important for flexibility to keep such dependencies to a minimum. The main way to order tasks in the Scrum process is by priority. To see and change priorities click on the "Priorities" button on the Tools pane. Here's what you might see...

The priorities of all the tasks in "Sprint 01" are all the same (they're all priority one!). As a result the scheduling of the tasks is effectively random. Let's prioritise then in alphabetical order. Here's what the priorities list looks like then...

Changing priority changes the order that the tasks are scheduled, so the Gantt chart now reflects the alphabetical priority ordering. Here's the resulting Gantt chart for "Sprint 01".

And here's the projected Burndown chart for the same Sprint. It still shows a red status as we've not removed tasks by prioritising, but it reflects when the newly ordered tasks are forecast to close. For more on how burndown charts are used as the Sprint progresses, see "Don't burn out - burn down!".

The next article in this series looks at the significance of Top-down or Bottom-up planning for Sprints.