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: 41%

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

Dr. Samir Shah from Penn State University will present a talk at Mukesh Patel College of Technology Management and Engineering, Mumbai through Agile Mumbai User Group [A-MUG] on 6th February 2008 at 6 PM. The talk is expected to last 2.5 hours.

Dr. Samir is going to speak about his PhD thesis on Distributed Development using Agile and traditional models. He conducted 2 distributed projects between India and US. One of the projects used traditional methods and another one used Agile. He has some really interesting observations about each project that he would share with attendees.

You can RSVP for the event at nashjain@gmail.com

Popularity: 14%

Posted on January 26th, 2008 by admin
Filed under: News | No Comments »