The First Scrum Sprint is Going to Suck

If you’re new to Scrum then we need to get something out of the way. Your first sprint in scrum is going to suck. That’s the bad news, the good news is that your probably switching to Scrum because whatever your doing right now also sucks so you won’t be any worse off.

So if Scrum is so awesome and solves so many problems why will my first sprint suck? Well, you see Scrum doesn’t actually solve your problems for you, it exposes the problems that were already there so you can fix them.

Let’s use estimates as an example, if you’re not already estimating your workload before you commit to it then you might as well give up before you start, you’re almost guaranteed to bite off more than you can chew. This problem gets even worse if you do estimate your work items far ahead of time when new requirements or changes can still happen. That simple change you guessed would only take 4 hours has now become a major undertaking and you committed yourself to completing it in this sprint. The answer here is obvious, create your estimates during the sprint planning meeting so you never commit with an outdated estimate. This is exactly the kind of thing we might have overlooked and continued doing were it not for a small failure during a sprint.

That small failure is the real reason why sprints are so important. Failing a release is a Big Deal and nobody wants to be invited to that party but failing a short sprint (while not fun) is not the end of the world. Fail a sprint, learn a lesson, improve and make the next sprint better. With continuous improvement you may find that you'll be making up for lost time towards the end of the release anyways.

*Bonus, you can take this experience into this next release as well.

Bottom line: Nobody likes failing a sprint, but it’s an important part of Scrum and in the end we should try to avoid assigning sprint success or failure with a value like "Good" or "Bad". Each sprint is there to teach us something, either a sprint is succesful and it confirms a strategy that works or we fail the sprint and it highlights something that needs to be changed.

Try to avoid it but failing your first sprint (or first couple sprints) will give you some important clues as to how Scrum will fit your team over the long haul. More importantly, keeping your development cycles in sprints keeps your failures limited to a small timeframe of the overall project, thus giving you some room to experiment.