Making the Sprint Backlog Ready for Testing
In his article “Creating an ATDD Ready Sprint Backlog in Scrum“, Ralph Jocham discusses the requirements definition in Scrum and how examples allows the team to better understand them. As the backlog is now also expressed in terms of business requirements, each team member can easily focus on the bigger picture during the Scrum stand-up meeting and align with the ‘why’. If you translate the business-facing examples into automated tests, it enables the team to verify during the Sprint that the software increment always meets the evolving requirements towards the Definition of Done and the overall goal.
In his proposed approach, a set of acceptance criteria are defined for all the user stories of the product backlog that are included in the sprint backlog. One or more examples are specified for the acceptance criteria. For each example. an acceptance test is written which will fail as the business functionality has not been programmed yet. Then the functionality is coded using a TDD approach. When the test of the example passes and turns green, it means that all unit tests are passing and the acceptance test is working according to the example. This approach seems initially very time consuming, especially for developers not well versed in writing tests first. It is however the basis for a long time sustainable high product development velocity. It allows for fast regression testing which is mandatory when throughput and quality are important.