A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Scrum – Being able to better complete the schedule through refining scope of work

This post is more like a comparison between the version of Waterfall we used to do whereby we would have a great project plan using MS Project, whereby we would have the requirements stage, the design and architecture stage, following by development and testing stage. When we would run the project in this manner, we would have all the requirements defined early on and we would do the initial estimation of features that could be completed soon after the start of the project. In this kind of scenario, we would actually start implementing all the features and reach a point called Alpha whereby all the features were implemented, but there was a large amount of defect finding and defect fixing to be done. From this point onwards, it was a tough battle. The amount of work that was needed to be done was not really trackable through a MS project sheet since it was all defect finding and fixing, but the timelines were known. Even if we were able to finish the entire project within schedule, it was never easy. There was always a large amount of pressure on the team for all the defect fixing, and you just kept on hoping that the defects were being completed within schedule and the slope of open defects number kept on reducing in a straight line that fits within the schedule. The major problem you have there is that even though the defect fixing stage of the schedule can vary between 30-50% of the entire schedule, you are already locked in with your features having already been done and not having the ability to make changes in scope of the features to handle the schedule pressures.
And this is where Scrum can really make it useful for the Product Management (actually done by the Product Owner as a part of scrum) and the Project Manager (there is no direct equivalent, since the team handles most of the work and the Scrum Master can help in coordination but does not have authority to get status when he/she desires it). As a part of the Scrum cycle, the entire schedule is composed of Sprint cycles with definite feature goals for each Sprint cycle. Through the Daily Scrum meeting, the team can easily figure out whether the initial effort approximation was correct or not; if it turns out that the team is lagging behind since it is taking more time for the features and fixing, then the Product Owner can actually look to re-scope the features and tasks to be done in the next Sprint to ensure that the critical features and tasks to be completed within the schedule and at a high quality (and that too without causing burn out in the team). When a Scrum team works well, it is able to ensure that they are able to adjustments to the features and tasks so that the team knows that they will meet the schedule.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>