An iterative development model such as SCRUM is a very powerful mechanism for change control. In any project managed using typical waterfall models, every change proposal had to go through an evaluation process to estimate it's impact on the project deadline. Sometimes, even if a proposed change is beneficial to the product, it gets rejected because of the amount of rework to be done by the development team and/or its impact on the deadline.
An iterative process, on the other hand, deals with this problem very elegantly by maintaining a narrow time window within which specifications gets frozen, and development work is done only within this window. This window is an iteration, known in SCRUM as a Sprint, and is typically 1 month in duration. The other teams may modify any task on the backlog which has not yet been taken up by the development team.
At the start of an iteration, the development team looks at the Product Backlog (which has the highest priority tasks at the top) and identifies a certain number of tasks from the top which they believe they can complete within the one month sprint. A more detailed explanation of this estimation technique is given later.
Once the tasks to be undertaken in the current sprint (or iteration) is identified, they are moved into the sprint backlog and the team starts working on them. At this stage, none of the other teams and stakeholders may subsequently alter any of these tasks.
The work done on a task within the sprint is a mini-project in itself, and typically covers all stages of development, from design, development, testing, documentation and integration.
An iterative process, on the other hand, deals with this problem very elegantly by maintaining a narrow time window within which specifications gets frozen, and development work is done only within this window. This window is an iteration, known in SCRUM as a Sprint, and is typically 1 month in duration. The other teams may modify any task on the backlog which has not yet been taken up by the development team.
At the start of an iteration, the development team looks at the Product Backlog (which has the highest priority tasks at the top) and identifies a certain number of tasks from the top which they believe they can complete within the one month sprint. A more detailed explanation of this estimation technique is given later.
Once the tasks to be undertaken in the current sprint (or iteration) is identified, they are moved into the sprint backlog and the team starts working on them. At this stage, none of the other teams and stakeholders may subsequently alter any of these tasks.
The work done on a task within the sprint is a mini-project in itself, and typically covers all stages of development, from design, development, testing, documentation and integration.
No comments:
Post a Comment