We’ve all been there, everyone working hard and before the team know it the testers find they are blocked until the developers have finished and we’ve run out of time…
Some of the many interesting points raised during the discussions:
A key to preventing this occurring was felt to be clear communication within the team. The team needs to be constantly reviewing what’s in play (at the daily scrum) and reviewing and refining the stories both upcoming and in sprint. The team needs to work together to effectively plan the work taken on to make sure the best use of available resources.
The Cross Functional Team
The Dream Team. In the ideal team, members could work on both testing and development. However it needs to be clear for the team that a story isn’t finished till it’s completely done and that the team needs to take ownership of the stories. If the development work has finished, the developers could be looking to assist the testing rather than seeking to draw new stories into the sprint.
An issue brought up that can lead to this problem is Team makeup. We’d all had experience of dev or test heavy teams. If the project is looking to be test heavy can the team be tweaked to bring more test resources into it and potentially even tweak once the project is under way. This is more problematic in smaller companies, not exactly necessarily in the scrum spirit and would impact velocity measurement (and so planning) but it may need to be at least considered.
Staged Delivery within a Sprint
Within a story itself there maybe opportunity to provide some of the code to the testing before the feature is fully written. A great example of the “Happy Path” was given, by this it’s meant that the developers work on the easiest path through the story initially, not considering the edge cases – this means the testers can get started earlier, and while the testers are working on that aspect the unhappy paths can be developed. This way testing on a story that might take 5 days to complete coding could start on day 2 rather than wait for day 5.
In addition is the story completely blocked? The test effort could potentially start with data setup and preparing test scenarios ready go – though this is normally the situation anyway.
Order of tasks
The groups seemed to agree that there is a natural tendency to start the biggest/most complicated story in the Sprint first – this can lead to a delay in delivering anything for the testers’ progress. Is it in fact more efficient to deliver the smallest/least complicated story first – this should lead to short delay in the testers being able to complete the first story, and everything potential fits together more efficiently.
Could it be the team was taking too much on?
One point that was raised is that if the team is continuously find itself blocked and so isn’t delivering the stories committed to, may mean that the team is bringing too much into Sprints and setting itself up to fail. In a similar vein the team should consider the size of the stories and can they be broken down into smaller stories?
One possible solution which was considered not to be effective was the concept of staggering the work – the developers work on the next sprints stories in the current sprint to “get ahead”. This proves too problematic once testing is underway and issues are found. The developers then have deal with these issues and soon find themselves having to deal with (from their point of view) old and new stories at the same time losing focus. It’s also not really in the spirit of Scrum.
All in all a very interesting discussion and some great ideas put forward!