Scrum is a lightweight, iterative and incremental framework for managing complex work. It is designed for teams of ten or fewer members who break their work into goals that can be completed within timeboxed iterations called sprints. (Source: wikipedia.org).
In RWS Moravia, teams mainly consist of Developers and Quality Assurance Engineers. In other companies, Designers, Analysts or Architects may also be involved. This variability in skillsets often causes work to be sequenced: Developers must complete their tasks before sending them to the QA Engineers. Do you remember the classic waterfall model, where implementation is followed by testing? This looks pretty similar, just on a smaller scale—one sprint.
Often, this means that QAs have a lot of work piled up at the end of the sprint, resulting in finding bugs on the very last day. This causes unfinished stories in the sprint, developers angry at QAs because they did not finish the testing, angry Product Owners, unsatisfied business owners…you get the idea.
I raised this issue during the EuroSTAR Software Testing Conference (link: https://conference.eurostarsoftwaretesting.com/) and OPEN Space inAgile (link: https://www.openspaceinagile.cz/) and here are the findings:
Split those stories!
Imagine there is a team of three Developers and one QA Engineer. The team will take three big stories into a two-week sprint, and the Developers finish them in the middle of the second week. How then is it possible for the QA Engineer to test all of them in the remaining two days?
Instead, split big stories and deliver them as soon as possible within the sprint. For example, if the first story is delivered on the second day of the sprint, the QA work is much more evenly distributed. If you need to include a big story in the sprint, making it an exception, also include small stories and reserve enough time towards the end of the sprint to QA the big story.
Remember that even split user stories need to deliver clear business value, and not just be technical tasks.
Work in parallel
Identify steps that can be done in parallel with development, ideally during refinement. These may include preparing test scenarios, gathering test data and writing automated tests. There is nothing better than finishing development and immediately executing an automated test suite to assess its quality.
Hand over Work in Progress
It is not necessary to wait until all development is finished to test it. For example, the database component of a story can be finished and tested while the frontend is still being developed. Or, ideal path scenarios can be tested while exceptions are still being developed.
Stop starting, start finishing
We can learn from Lean (Kanban) and limit Work in Progress. This will lead to closer cooperation between team members and faster delivery. Two teams from different companies at OPEN Space inAgile talked about having a WiP limit of 1, meaning that only one User Story can ever be In Progress. They claimed that this limit caused their overall delivery to increase!
What I would like to also mention is that it is absolutely critical to strive to deliver all planned User Stories within the sprint. Some teams are tempted to let User Stories overflow from one sprint to another, therefore seemingly making the issue disappear. If the team does so, they will lose the focus that sprints provide.
If you want to know more about how we work in RWS Moravia and what we learned along the way, just follow our blog.