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

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

Product or project backlog is perhaps the single most important artifact in an Agile project. Here is a quick FAQ style introduction to product or a project backlog:

Question: What is a Product or Project Backlog?

Answer: A product or a project backlog is a prioritized list of requirements with a rough size and complexity estimate of each requirement. Hence, the backlog has 3 components: requirements, priority, rough size and complexity estimate.

Question: Who provides the requirements in Product or Project Backlog?

Answer: It is typically the role of a product owner or a customer to provide the requirements. However, sometimes analysts from the development team can work with product owner or customer to define the requirements. The idea is for the product owner or customer to work with the team to discuss the requirements during the sprint planning meeting.

Question: How are the requirements written?

Answer: There is no standard way to write the requirements. One team can simply write “users sign in” and another could write “users should be able to sign in with their email address and password”.

Question: Is additional information captured in the requirements?

Answer: Yes and no. It depends on project to project and requirement to requirement. Something like Forgot Password might not need further information but something like User Registration might have various notes on each field like date of birth (should be 13 or more) and password (strength).

Question: Do we require “acceptance tests” for the requirements?

Answer: Yes, highly recommended. However, having acceptance tests for all requirements would be too time consuming. Also, the team and product owner or customer should discuss the acceptance tests for each requirement in detail during the sprint planning meeting. It is useful to remember that Agile is collaborative and both the customer or product owner and team should discuss and agree on “definition of done” before the start of a sprint.

Question: Do we need details on everything for each requirement on the backlog?

Answer: This is not really required, although nothing stops you from going this route. However, the closer the requirements are placed to the current sprint, the better they should be defined.

Question: Do we need to estimate each requirement in the backlog?

Answer: Yes, it is recommended that each requirement be estimated. The requirements far from the current sprint can only be coarse grained and hence roughly estimated. However, this gives product owner or customer a rough idea of the project size and number of sprints required to complete a project. The final number of sprints could be more or less, but at each stage the visibility of progress would be self evident.

Question: How is the estimate done - in days or in hours?

Answer: You could use either, although relative estimation would work better. The team and product owner get together at sprint planning meeting. They pick up the simplest requirement from the list and arbitrarily assign a number to the same [say 1 or 1 requirement point or better still 1 coffee cup]. All other requirements are estimated in similar units [requirement points or coffee cups]. At the end you total up the points. At first the team could take a guess at the amount of points it could complete in a sprint. After a few sprints, they would have visibility of how many points they should ideally take. This estimation technique works well to give you rough idea of work that can be picked up. Its not supposed to be used for precise calculations or a point in horizon rather just aim for a region in horizon.

Question: How do we estimate - based on size or complexity?

Answer: The short answer to that is both! Entering 1000 records in database might not be complex, but time consuming and on the other hand investigate SOA performance issues in reports in a clustered environment may be complex and hence, difficult to even give a precise estimate on. And in some cases, you might want to factor in both. Hence, you estimate both from difficulty level as well as effort required.

Question: How is the backlog prioritized?

Answer: It is the responsibility of product owner or customer to prioritize the backlog. The team can provide assistance in the same though. The backlog is prioritized by factoring in risk factor of not doing the requirement right now and opportunity by delaying the requirement decision later. In simpler terms, risk factor, dependencies and business value would help the team decide the priority.

Question: Does the backlog provide any tracking?

Answer: Yes, you can make a simple tracking of completed/ pending items. You can also track number of requirement points completed in a sprint and based on average requirement points completed in a sprint and total requirement points pending, you can get an idea of the projected completion date. The average requirement points completed in a sprint is also called velocity.

Question: Is there a low level tracking involved?

Answer: Yes, you can divide each requirement into tasks. Each task can be estimated in number of hours it would take to complete. This is typically done only for a given sprint and is called a sprint backlog and is maintained separately from product or project backlog.

Question: Is the product or project backlog only made once - at the start of a project?

Answer: No! There are only two rules. First,the product or project backlog should be revised and continuously updated based on emergent scenarios and situation. Second, the backlog for the sprint currently in progress can’t be changed. The backlog for upcoming sprints can be changed almost completely. In a fixed price scenario, this might mean you need to swap new functionality with existing functionality.

Popularity: 48%

Posted on January 15th, 2008 by admin
Filed under: Business Alignment, Collaboration, Introduction, Practices | 5 Comments »