When a new Scrum team takes their first swipe at estimating the tasks for a sprint, there is a lot of guessing that necessarily has to take place. They are still getting used to the very idea of “done, done, done” and so the engineers have to just take their best shot at estimation. Small stores help here (see INVEST), but it still takes some experience before the estimates smooth out.
One of the things that bite developers is the same thing you see on traditional waterfall projects, but happening in the timeframe of the sprint — that is, things getting all bunched up at the end. Then you run out of time, QA gets shorted, the QA folks (which could be the whole dev team) get stressed, and in your retrospective you try to figure out how not to do THAT again. For new teams, there is an “X” where the crossover happens between dev efforts going down and transitioning to fixing, and the QA efforts coming up to full speed. The team then tries to figure out how to “move the X” so they don’t run out of time at the end of the sprint, which is where this Scrumism comes from.
This happens in part because all the developers attack individual stories so they are on parallel tracks, each with QA at the end. The way to move the X is to finish up dev earlier, as well as putting more of the QA efforts in the dev work – which can take the form of better unit testing, dev starting up the basics of automated testing used by QA (e.g., Selenium tests), and the like.
In a theoretical world, with all developers able to work on any story, you get an effect where you can actually erase the X. If the team is able to swarm, then you can fully knock out a story to completion and then swarm onto the next one. You get an advantage from this approach (and yes, I did mean to leave a little extra time at the end of the sprint in the figure below). Few teams can fully swarm this way, so you will likely still see the competition for QA time at the end of sprints.
