In our last post we provided a brief introduction to Sprint Backlog, we discussed, how at the end of the sprint planning meeting, the team comes up with a reasonable estimate and breakdown of effort involved in converting the requirements to completed functionality. The detail of effort needed is usually called “task breakdown” and can be equated to “work breakdown structure” as mandated by “defined process control”. Often, this would be captured in a document format and at the end of sprint planning meeting, this looks like this:

After devising this backlog, the team gets down to work. However, the team visits the backlog once a day [typically after the daily stand up]. Basically, the team would update the backlog in these ways:

• They will update the hours remaining for each of the tasks. This is a subtle shift from traditional methods. The team is not recording “how many hours they spent on a given task” but “how many hours are left”. This is important because measuring how much you have come to makes sense in a defined journey [going from Los Angeles to San Francisco for instance] but not in software where you can only “estimate” the journey. Also, at all stages you can only manage whats coming ahead rather than whats past. However, some teams would track hours spent for tasks. This can be for purposes like estimation information for future or timesheets. However, like all things in Agile, it is left for the team to decide if they want to measure the time spent or not.
• The team can add/ edit/ delete tasks to the sprint backlog. There can be tasks that are discovered, as they work on requirements during the sprint. The team can take a task and break it into two or three or more tasks. The team can find that a given task is not needed [for instance UI secondary review or training for any technology] and hence, delete these tasks or keep the time remaining for these tasks as zero, from the day they discover, they don’t really need these tasks. This is especially true for tasks which can be completed in many ways [you can organize training for two people or get two new people on board for instance]. For each task deleted/ added/ edited - the team would discuss the reasons why the same had to be done during sprint review, especially if they are not able to complete the sprint target [complete all given requirements to working features].
• The team can re-assign a task to another team member either before the task has been started to be worked on or while it is being worked on. The “Responsible for” person column then has two names rather than one name.

After about 3 days of working, our backlog, after 3 days of regular updating, could appear like this:

Looking at above, lets understand sprint backlog a bit more:

• It appears that there are some tasks went fine - the team took them on and completed them [most of the tasks in white belong to this category]. However, on a closer inspection of the backlog, you don’t really know. You don’t know if the task was completed fine in the time the team originally estimated or whether team did it in less. This is because at the end of sprint, the first question you want to know is whether the task [and requirement] is completed or not. If all requirements are being faithfully developed into functionality, consistently and the team performance is improving every sprint, details of time spent/ exceeded seem trivial.
• Similarly, lets review the tasks highlighted in blue. We know at end of day 3 - the time remaining for the tasks is as much as we estimated. However, we do not know if the team has been working on these tasks at all or working hard enough but getting stuck after 8 hours of work. Interestingly, the task in yellow “Integration Testing” has more work left after 03 days. This can be due to rework, stringent or new quality checks or poor coding. Such details and patterns are easily observed using a “time remaining approach” and the team can discuss the same during sprint review meeting and possibly come up with root causes for why this is happening. Once, the root cause is identified, the team can devise a solution to overcome that.
• The task in green [last task] was discovered on third day and added to the backlog that particular day, while load testing of Member Sign In was assigned to two people.

After 05 days of updating, and before the sprint review, the sprint backlog could look something like below [this is ideal and hopefully the teams would get there after 3-4 sprints]. Any task not completed means corresponding story is also not completed.

In our next post, we will review the philosophy behind “time remaining approach” and “why is sprint backlog designed the way it is”.

Popularity: 10%

Posted on February 10th, 2008 by admin
Filed under: Collaboration, Introduction, Practices | 1 Comment »

Often the teams like to construct a sprint backlog after the product or project backlog. While a project backlog is a high level description of requirements or features, a sprint backlog is a backlog of specific tasks for a particular sprint. Often it is also useful to have each of the tasks relate to a particular requirement. As an example lets use the following project backlog for any random sprint and any random project:

The above can be considered to be a product backlog for any random sprint with a sprint [n-1] before it [completed] and sprints [n+1, n+2, n+3 and so on….] yet to come after it. After the team has asked the questions from the product owner and estimated at high level using relative measures the size/ complexity of each requirement, the team gets down to divide the requirements further down into actual tasks. These tasks are all that is needed to complete a requirement. Everything means everything. An example breakdown can look like this:

The above is just an example breakdown into tasks and not representative. There might be more or less tasks, depending on complexity. For instance, we have taken out UI design completely from the breakdown and there might be projects where this is very important. Also, it can be readily seen that there are total of 05 working days available during the sprint and the requirements must be “done, done” at the end of 05 days. However, even a simple breakdown can help us note the following:

• The team has taken each requirement, broken it down in tasks and estimated the tasks in hours.
• As the team has not started working on any task, all tasks are pending and work remaining for each of the tasks is as the team has estimated.
• It is important to understand that the team should think of all the tasks it can for each requirement so that the requirement is really done, note it down and estimate it as best as it can and then quickly move to the sprint.
• The important idea is not to get a precise estimate of hours but an indication of effort/ tentative plan.
• If the team needs to add a task midway, then the team should definitely do so for each of the requirement. For instance, team might identify that it needs more integration testing for requirement 1 after all requirements are done and adds this to the backlog. The important idea is “if it needs to be done, it needs to be on the backlog” and “relate to a requirement“.
• The team members generally volunteer for each of the tasks and in case of a tie, confusion or no ownership, Scrum Master can help the team reach a decision on who does what task.
• During the sprint, often team members would help each other and even swap tasks. This is again acceptable and only condition is that sprint backlog should be updated.
• As can be seen, the sprint backlog would be updated each day and at the end of each day you will know exactly where you are and if you are headed for completing the requirements or not.

In our coming posts, we will give an overview of how the team updates the sprint backlog.

Popularity: 13%

Posted on January 28th, 2008 by admin
Filed under: Collaboration, Introduction, Practices | 1 Comment »