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: More detail on tasks ensures better quality

This post is likely to be somewhat controversial. I have had people coming to me who have had experience with both Scrum and Waterfall development methodology, claiming that by using Scrum, the team tend to ensure that they have a better overall quality of code and features that are being generated. At the same time, I have had other people claiming that it is not Scrum, Waterfall or other development methodologies that end up determining the overall quality level in the product, it is the way that the team works. And the problem is, I agree with both those points.
When you have a team that is very dedicated and sure of how to get good quality levels, they are likely to ensure that there is sufficient time given for the preparation of test plans and cases, as well as for execution of code review, test plans and cases so that there is a high quality expectation. But in most cases, what people see is that teams do not do so well in all these processes. Project schedules bases on using large MS Project files with their tasks may not cover all the granular level details of preparation of test plans, test cases, code reviews, etc. When there is pressure on the team, then the pressure of ensuring that schedules are met can mean that teams do not end up doing tasks that are not there on the schedule (and have not been estimated for), which can lead to an overall reduction in quality levels (Note: I do not mean to say that this will happen every time in a Waterfall type project, but there are chances that when there are schedule issues, such misses will happen).
My experience with Scrum teams and with people who have worked with Scrum teams is that the imperative to ensure that tasks have been estimated and created ensures that there will be tasks for every work that somebody is doing. This ensures that tasks for tracking of test plan and test cases are planned for and will be done. The same goes for tasks related to code review, and for defect testing and defect fixing. The tracking of tasks that can only be a few hours long ensures that the team does capture all these tasks and then, in the Daily Scrum meeting, also talk about their progress in the actual work of these tasks.
This kind of attention to detail in terms of tasks and the fact that the Daily Scrum meeting acts as a place where the team provide updates to each other about their tasks and the level of completion enables a team to be sure that all the tasks that can ensure a high level of quality are already there. In a normal Waterfall development model, if the project document has enough detail in terms of tracking such tasks, then one can be assured that all these will happen. However, when these tasks are not tracked by the Project Manager and it is upto the individual team members to ensure that such tasks are done, there is a probability that some of these tasks will be missed.

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>