Here I present an elegant tool implementation for use in SCRUM sprint planning – the nested sprint list for fluid effort estimation. Using this nested approach, the sprint effort can be determined using the summed sub-task time estimates for instant sprint effort planning. Use of the free Abstractspoon ToDoList windows app provides a particularly elegant way to do this.

 

Introduction

The idea of a task hierarchy within SCRUM is not novel. Sprints can be presented as an indent to the product backlog and in turn the sprint content as a further indent to the sprint. In sprint planning the team selects tasks from the product backlog as content for the sprint. The effort associated with each task is also estimated either in terms of absolute time or in relative terms (perhaps on a 1-3 scale for example). Ultimately the estimated time should match to the time available and also allow reasonable sharing of the effort across team members. For the latter in particular, an elegant approach is presented.

 

Concept

Previously I had written about a new todo list concept – the Matryoshka todo list. This idea involves the nesting of time periods in a todo list. So for example, Month will be a sub task of year, week a subtask of month and so on. Then for each task that comes it is slotted into each of those time periods depending on when the task will be done, today, this week etc. Summing the estimated times for the tasks in each time period allowed for an assessment if the tasks can be done in that time period and what time is available for new tasks. This can be explained by the use of task containers, shown below. As new tasks are added, the containers fill up. This equates to a worker’s time being occupied by tasks. The space remaining in the container reflects the available time. Of course as tasks are executed space becomes available for new tasks.

 

 

When doing this I realised the same concept would be well suited for sprint planning. Instead of nesting the time periods, nested sprints could be done. This idea is shown in the next section as a sample implementation.

 

Implementation

To implement this idea, I use the free software – Abstractspoon ToDoList. This is available for download here. Each sprint is shown as a subtask of the product backlog. During the planning process, tasks are simply moved from the product backlog to be a subtask of the relevant sprint. Each task will have an estimated time associated with it. Then using the built in features of ToDoList, we see the summed time for the sprint.

Abstractspoon ToDoList also supports multiple filter and task search options that can be applied to the list. One omission here though at present is the ability of the summed estimated time to account for the filtering. I can see situations where this would be desirable. For example, if a filter is applied for each team member, then ideally the summed estimated time would only be for that team member.

Final Words

I think this nested approach may be another useful tool in the arsenal of SCRUM Masters and indeed for other task management applications. If you have any other idea, feel free to let me know!