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 – Tackling the issue about less work for QE team in the early part of the cycle ..

One of the constant issues that we hear on a regular basis is about the imbalance in terms of teams being busy during parts of a Sprint rather than through the Sprint. For example, one of the biggest problems reported was that the development team would be busy during the early parts of a Sprint, and after they had made the delivery of their components to the testing team, that would be the time when the testing team would become busy. The expectation was that things need to be configured such that this sort of cycle needs to be avoided, and that the testing team should not be busy only for parts of the sprint, but through the sprint in order for the productivity of the team to be increased and kept at an optimum level.
If you keep the normal cycle of a Sprint in progress, it would follow that the team would be given tasks, they would estimate and bid for the tasks, and then would start working on the tasks. However, this also meant that if the developer had a task, there would be time involved in doing design for the task, there would be the working with the user designer in order to get the dialogs and other user interface ready, and all of this would happen during the Sprint. It was only when all this was done, and then coding happened would this work get to the tester for actual testing, and in some cases, the amount of time available for this testing was a stretch, because the Sprint done timeline was coming up fast and there would be a lot of hectic work involved in testing, defect fixing and re-testing.
One idea of course which works in many cases is to re-look at the breakup of the tasks that are being assigned to the development team. If there are many days that go by before the work can be given to the testing team, then the tasks are not being broken down into smaller sections as much as desired. If the tasks can be broken down to 1-2 day sections, then the testing of those tasks can start very early, and the time duration in which the tester apparently does not have enough to do is reduced.
The next thing to do is to not have loading of the design of the tasks in the current Sprint, but ensure that all the major design work, especially the interaction with the Interface and Visual Designer happens in an earlier Sprint, captured as a separate task. Working with the designer for workflows can take time and be iterative in nature, and putting this in the current Sprint along with the development (writing of the code for the same) can lead to the same problem about the testing team not receiving it in due time.
Yet another item is about ensuring that the tester team is also working towards preparing the test plans and test cases for the User stories. These are based on the requirements, and not on the code that the developer is generating, and so can happen in parallel with the development effort and ensure that the testing team has enough on their plate to do in the early parts of the cycle. Combining these approaches led us to ensuring that we had lesser of this problem of the testing team sitting with not enough tasks, but it would still happen sometimes.

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>