Tales of the Bizarro Scrum – The Code Freeze

  • Post author:
  • Reading time:2 mins read
You are currently viewing Tales of the Bizarro Scrum – The Code Freeze

Developer: “We do a code freeze 2 days before the end of the Sprint so we can start testing.”

A statement like this typically means the team is not applying agile engineering practices, the team doesn’t properly break out product backlog items into small vertical slices, and the team is working in a mini-waterfall approach with members still working in silos with hands-offs from business analyst to developer to tester.

Applying proper agile engineering practices like automated acceptance testing (AAT), test driven development (TDD), and automated deployments ensures that the team is building quality in and removes the need for code freezes and long testing cycles at the tail end. In Scrum, testing starts on day 1 and continues throughout the Sprint. There is no distinction between programming or coding and testing. It’s just quality development. It’s about building quality-in instead of checking for quality later. Various types of automated tests are created by the Scrum team to ensure the code works as intended and as per the requirements. This includes unit, integration, system, UI, end-to-end and User Acceptance among others.

Breaking out user stories into small vertical slices ensures the team is completing stories 2 to 3 days into the Sprint as opposed to working on the same large stories for almost the entire Sprint.

Finally, a Scrum team works together collaboratively with the developers handling the bulk of the test automation at the unit, integration, system, and UI level while the testers focus on User Acceptance Testing, exploratory testing and usability testing.