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 »

In her presentation at Agile 2005 Workshop, Mary Poppendieck, talked about 1/3-2/3rd contracts. We think this is an interesting way to structure a collaboration schema for engagement of Agile teams. Here is how it can work:

• The team/ analysts get together with the product owner or customer and write down the requirements and understand the acceptance scenarios as well as objective for each of the requirement.
• The product owner or customer would prioritize the requirements to arrive at a “can’t live without” list of requirements. You can use YAGNI for business value as well.
• The team can provide an estimate of the complete project using whatever estimation methodology they choose.
• The team then calculates what is one-third the time of the project.
• Based on the initial requirements list, the team and product owner would further narrow down only the main work flow requirements.
• For these requirements, the team does further analysis to define acceptance scenarios, presentation and task planning.
• The team develops a no whistles working version [yes it does calls to database and all functionality is actually working] of the project in 1/3rd the time.
• After 1/3rd the time, the team can get together with the product owner and review the functionality.
• After this, we would encounter the following scenarios:
  • If the product owner or customer like what is happening and the original requirement list still stands - continue and develop the project with the confidence that it is moving in the right direction.
  • If the product owner or customer don’t like what is happening and would like to change the requirements or assumptions, then you can do so. Although, this is not ideal, it is still better to do this when you are only 1/3rd done than when you are a 2/3rd done or worse when you are 100% done.
  • More than likely the process of actually getting down to development would uncover and test hypotheses, priorities and assumptions used while actually developing a project and generate new and better idea on how project should actually be developed.
• If you do not decide to change, then the original contract still stands. If you do decide to change, then the team and product owner can discuss the project from a new perspective [almost like a new project].

It is important to note that working version of the functionality above is different from a proof of concept. Proof of concept focuses on determining feasibility of an idea or approach, rather than determining the usability or effectiveness of ideas or approach. The proof of concept might be a step in the 1/3rd - 2/3rd approach but not by itself would be a complete 1/3rd of the project. A software prototype can sometimes work as good way to approach 1/3rd of the project. However, for a 1/3rd - 2/3rd approach, you actually develop 1/3rd of the project. For one project user interface might be the single most important aspect and hence, that would be first addressed during the 1/3rd of the time via a click through prototype. For another project, a core workflow of how various members interact would be important and hence, calls to the database might be important. The 1/3rd of the developed project is incrementally and iteratively enhanced and not thrown away unless found completely unusable.

When the product owner or customer and the team are on their first project or first release together, they can estimate the project in detail. However, as they understand each other and learn to work with each other, the estimates and requirements discussion can be high level or as low level as needed. Hence the above process would work like this:

Rough requirement discussion — ballpark estimate provided — 1/3rd of estimate calculated — 1/3rd of requirement list discussed — 1/3rd requirement list detailed — 1/3rd requirements developed — Feedback

The advantage of this approach is that overhead of meetings and discussions is less and you actually get down to focus on your core functionality sooner.

An important question is to understand why 1/3rd and why not 1/4th or 1/5th or even 1/2 of the project. Well a simple answer is that you can pick a number as you want. For a risky project or unclear domains it is recommended to ruthlessly prioritize and re-prioritize your requirements, you could go to as low as 1/5th of the project. Using the Pareto’s Principle, 20% of all requirements would generally give 80% of all business value. However, doing anything more than 1/3rd is keeping feedback away longer and hence, inherently more risky on relatively risk free projects. If you have multiple workflows that would need to be tested, prioritizing is important. If this is not at all possible [which is highly risky as well], you can start two 1/3rd approaches relatively separately. Even if a contract is not specifically constructed as a 1/3rd - 2/3rd contract, it makes sense to develop each project in this way.

Popularity: 11%

Posted on January 18th, 2008 by admin
Filed under: Collaboration, Outsourcing 2.0, Pricing | 1 Comment »