Joelaadams
Profile Answers by Joelaadams

Jun 29th, 2010

Scrum sets out a fixed length for each Sprint (In classic SCRUM, 30 days or four weeks). Hence, if you are running ahead of schedule, it will be necessary to add tasks to avoid idle time at the end of the Sprint. Conversely, if some tasks won't be completed by the end of the Sprint, they should be removed now. This keeps the business side (Product Owner) knowledgeable about what is going on and allows the Product Manager to have input into what tasks should be added or deleted.

Problems can arise if you are too "sensitive" to running ahead or behind schedule. If you added tasks at the end of week one, it is embarassing to remove them at the end of week two. Early in a project, the team may not have a good grasp of its own velocity. And, if running behind, the team should first consider how to "make up for lost time". Dropping tasks should not become an "easy way out".

It requires some judgement from the ScrumMaster to decide when schedule concerns are serious enough to add or delete tasks. It is sometimes OK to simply not complete one task at the end of a Sprint.

Scrum Development in respects to the Burndown Chart

One popular tool in scrum development is the burndown chart, which diagrams the day-to-day progress that a scrum development team is making on a particular sprint. Essentially, at the end of each day in the sprint, the team estimates how many hours of work they still have to do to complete the sprint requirements. If all is going according to plan, the actual burndown will occur at the optimal rate, heading for zero hours of work remain-ing on the last day of the sprint.
Some scrum teams use the burndown chart as an indicator of when sprint requirements should be removed (i.e., whenever the actual burndown curve rises above the optimal curve) or added (i.e., whenever the actual burndown curve dips below the optimal curve). Explain the justification for this way of thinking, as well as the flaws with making these adjustments on this basis.