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: Testing getting done by the end of the Sprint / Or not

The question of testing tasks and Scrum is one of the questions that keeps on popping up at regular intervals. Teams that are initiating Scrum as their development process, or those that are running in a situation where there is a lot of focus on development tasks and less so on testing tasks have a number of queries and issues about the completion of testing tasks by the end of the sprint. I (along with other scrum masters in the organization) have run into situations where teams have done a lot of work developing a feature in a Sprint, and have then found that there were significant defects in the feature at the conclusion of a Sprint, and the feature has been added back to the Backlog for the next sprint. Such situations create tension in the team, but there are really no other alternatives if such a situation has been reached.
How does one handle this ? Well, one of the important tasks in this entire process has been to have a discussion with the entire team about ensuring that testing and the resultant defect fixing is completed within the Sprint, else the feature cannot be marked done at the Sprint end. It is very important to emphasize to the team and ensure that they understand that testing needs to be a part of the Sprint process, no matter what the power equations be within the team or in the organization (and we have seen cases where the developers tend to be treated much better than the testing team). If testing is not completed in the Sprint, then the feature does not get marked in the Sprint – it is that simple.
The idea is to ensure that the entire Scrum team understands this issue and buys into it. If this happens, then the next time that estimations are done for the User stories or features that will be taken up in the sprint, then there will emphasis to ensure that testing is also completed in the Sprint (it has also worked when we have had Sprints where features were not marked done since the testing cycle had not been completed for these features, since this ensured that the team got a good example of where the feature was not marked Done because testing was not completed). It also means that all members of the team understand the importance of ensuring that QE tasks are thought of, even if the actual testing is done by the testers within the scrum team.
The Daily Scrum meeting is where all of this is actually put in day to day practice. It is in this meeting that team members share their current tasks, and so, if the development team member shares details about the tasks / features that they are working, it is then the responsibility of the testing team member to evaluate the testing impact of the task (or a refinement of the estimate that was stated at the Sprint Planning meeting). This input then helps the team decide whether the feature will indeed get finished in time for the Sprint end, and if this is not the case, it helps the team decide on next steps in this regard (although some of those steps would need to be discussed with the Product Owner if these involve any refinement of the feature or the User story). In some cases though, when the team finds out that the feature will not get completed, it is indeed moved to the next Sprint, where the remainder part of the feature can then be estimated upon in the next Sprint planning meeting.

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>