Over a million developers have joined DZone.

The First Scrum Sprint is Going to Suck

DZone's Guide to

The First Scrum Sprint is Going to Suck

· Agile Zone
Free Resource

Speed up delivery cycles and improve software quality with TestComplete. Discover the most robust automated testing tool for end-to-end desktop, mobile, and web testing. Try TestComplete Free.

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.

Release quality software faster with TestComplete. Discover how to decrease testing times and expand test coverage with the most robust automated UI testing tool. Try free for 30 days.


Published at DZone with permission of Sean Mchugh, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}