Top-down or bottom up planning for Sprints

xProcess supports two ways to specify the required resources for a parent task: top-down or bottom-up.

The simpler approach is bottom-up. A parent task has subtasks with their own estimates of size and effort. The parent task size is therefore just the sum of subtasks' sizes.

What if you don't yet know what all the subtasks are? In this case - or if you want to specify some contingency or slack without inflating the estimates for the subtasks (Parkinson's Law would suggest this is a good idea) - then you can supply an independent estimate for the parent task by specifying it as top-down.

A previous entry, Parent Tasks and Top-down Planning, has already discussed this feature and shows the user-interface for using top-down estimates. The question here (since this is part of the series on Using the pre-defined Scrum Process) is how to use it for Sprints in Scrum.

Let's take a look at the current state of "Sprint 01" in our example Scrum project. Although this is quite a detailed screenshot, just look particularly at the red figures in the middle and the Alerts at the bottom of the screen (click on image to make larger).

The negative numbers for the estimates of size and effort for the "REST" of this task, and the Alerts, tell the same story. The backlog items in this sprint exceed the size of the top-down estimate. (See Prioritising the backlog for how and why these items were added to the Sprint.)

In this state the top-down estimate really is of no use since the larger amount of effort required for the child tasks will determine the time it takes and the top-down estimate of the parent task will effectively be ignored by the auto-scheduler. The auto-fix for the Alerts provides 2 ways to solve this situation:

You can either increase the estimates so that once again the top-down estimate is greater than (or equal to) the sum of the subtasks, or simply convert it to bottom-up so that the estimate for the Sprint just reflects the size of its parts.

So Sprints which already have a complete set of tasks added to them should usually be set to bottom up. However Sprints which do not yet have their backlog items defined should be top-down. That's why when you create Sprints for the first time they are top-down, and as a result you can see the forecast assignments for people and the projected cost of each Sprint of the project, based on its top-down estimate.

The general rule for how to decide whether to use top-down or bottom-up is this:

• if you think that you have captured all the work required in the subtasks, then use bottom-up
• if you think that having completed all the identified subtasks that there may be some others, then use top-down and provide an estimate for how large these other subtasks are in the top-down estimate.
  

These other subtasks are what is referred to in xProcess as the "REST" of a parent task, or the Remaining Essential Sub-Tasks. When you discover them you can create them in the parent task and task-by-task the size of the REST will be reduced, Or you may become confident as time progresses that you have indeed identified all the subtasks so you can then convert the parent task to bottom-up estimating and the REST will be removed.

One more point about parent tasks: team members cannot book their time directly to a parent task, only to a leaf-level task. So if they find that they are carrying out part of the parent task, but not one of the identified subtasks, they may need to create a subtask so they can book to it. This is another way in which the REST of the parent task may be reduced.

The next article on using the Scrum process in xProcess concerns configuring your process with Different Patterns for Backlog Items. Or if you're more interested in how participants on your project can use the xProcess web client, see Participating in the Project.