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 »

Its not uncommon to hear from Scrum teams - “we are sprinting, do not disturb” or “this could be handled in the next sprint” or “this sprint is going really well.” One of the first things, anyone learning about Scrum, should do well is to understand what is a sprint - philosophy and mechanics.Sprint in Scrum [or an iteration in a XP team] is a time period (can be anything from 2 to 8 weeks) in which the team does whatever it can to develop software as per the features/ requirements that the Team has committed to. At the start of a sprint, the team gets together with stakeholders [ideally represented by single entity called a product owner] and works out with the product owner, what features or set of requirements [which is usually called sprint backlog] will they be completing in this sprint. During the sprint, the team works on the sprint backlog. At the end of the sprint, the team demonstrates actual working software. The team also gets together to review its progress and what can be done better in the next sprint. Hence, a sprint is a time boxed period of time in which the team develops software as per its commitment.

The basic mechanics of a sprint in Scrum is centered on it being time boxed to a fixed duration. A 2 week sprint will end in 2 weeks even if all the work the team committed to is not completed. This is very important because:

• A fixed duration, imparts a rhythm to the process.
• The team gets better at identifying how much work to ideally commit to once it keeps working within fixed duration of time - this provides a great predictability to the product owner after a few sprints to plan releases around solid data rather than hope or complicated formulas not based on actual experience of “the” project. Additionally, the teams provides product owner fixed periods of engagement and review.
• The team also gets better at doing things within a fixed time period. Team reviews how well it has been working together and what can it do to get better. In a strange way time boxing provides the team tremendous opportunity to surface things that are the real obstacles. What its doing to each person in the team is tell them “You have a time boxed sprint to develop a given set of software with your team. Now, go develop and tell us whats stopping you from reaching your optimal collaboration.” Teams will [hopefully] identify everything that needs to be done and whatever is stopping them from doing it. And after a period of time get better at working together and work at a sustained pace.
• The product owner does not have to wait too long to make a change and trigger happy product owners need to wait at least 1-2 weeks to make changes. Hence, this will identify if your product owner is lackadaisical in providing feedback/ priorities and surface the obstacle. Similarly, it will also surface if your product owner is very fickle and keeping the team away from focus and stability.
• Finally, time boxing a sprint and self commitment to what it has to do in a sprint provides the team tremendous focus and goal.

Some other aspects of Scrum with regards to a sprint:

• There would be no changes in the team composition during the sprint and ideally over many sprints so that team can achieve sustainable pace in working together. Similarly, the team would commit to what it has to do and there would be no pressure to over commit. These are basically covered in the rules of Scrum.
• Product owners [or requirements owners] should be available through out the sprint to explain requirements to the team. This is important to provide marketing leadership through out the sprint for the team.
• The team would need someone to help the team surface obstacles, get better, explain Scrum and watch the Scrum process. This process leadership is generally provided by a Scrum Master.

Popularity: 8%

Posted on December 30th, 2007 by admin
Filed under: Introduction, Practices, Values | No Comments »