The Scrum Sprint – NOT a Mouse Wheel!

Thanks for reading the latest blog entry at

And — THANK YOU for waiting — a BRAND NEW comic strip. I am excited to get this new one out to you. I hope you enjoy…

A Sprint is typically 30 days (can be less — more for another posting) and a lot of places I go to and consult with look at the word “Sprint” as a bad word.

The general idea of a Sprint is for all stakeholders to get into a regular heartbeat of delivery (you know, so the team can deliver potentially shippable products on a regular basis).

For some teams, this looks like a continuous non-stop treadmill or running in a mouse cage (do you get a good visual on that now?).

And it goes on and on and on…. with teams never getting to “Done.”

This is sad.

How can you keep this from happening?

Well, I see a few ways that I’d like to examine today.

I want to examine how this is not a bad word or term and how it can be used effectively for sustainable development.

The whole idea of Scrum is to produce working software on a regular basis.

Working Software.

Say it with me now… “Working Software.”

Nothing else. Everything else is, well, not “working software.”

This does not mean the team has to forget about the differences between the Product Backlog and the Sprint Backlog (hmmm… foreshadowing my next two topics and comic strips) — because this is one of the ways a team usually gets to this point.

Think about it.

Who is committing to the work you are doing as a team during the Sprint?

If you are on the floor laughing, or have a blank stare on your face right now… let me re-frame the question to…

Who is SUPPOSED to commit the the work you are doing as a team during the Sprint?

If all else fails, what is the last thing we do before starting a new Sprint over again?

Stop and think about this.

It begins with the letter, “R”.

Retrospective is probably needed.

Maybe this means reading a book about it.

And I mean READING it until the end and then actually PRACTICING what you read about.

There is a night and day difference between a crappy Retrospective and a good one.  Retrospectives work.

Use them.

Find out why your team thinks the word “Sprint” is a bad word.

It should not be a never-ending cycle.



If it is…

Maybe it is time to perform an “Abnormal Termination” of the Sprint, call it a day, and go back to the Scrum Basics.

Hope this helps stop the insanity of never-ending-Sprints.

What else can you recommend to help stop this?

Send your comments and share some of your experiences.

Thank you!

- mike vizdos


  1. Mike,
    what on earth are you talking about? like extending sprints to longer lengths?

  2. Yes, “sprint” is a bad word. Think! There are athletes that can do 100 meters in under 10 seconds. Are there any athletes that do the marathon (42000 meters) in under 4200 seconds (1 hour, 10 minutes)???


    So why do you think a software engineer can??

  3. An athlete strives to get better and better in whatever they do. One of the reasons I do not think “Sprints” are a bad word in Scrum in because the Scrum Team (made up of software engineers and other roles) *tells* the outsiders what they will commit to doing.

    So. If the team wants to sandbag it and only commit to 50% of what they can really do, will the Product Owner or Project Sponsors really go along with that for a long time? I sincerely doubt it.

    If a team is being *told* what they *have* to do during a Sprint, then it is time for the team members, ScrumMaster, and Product Owner to take a step back and really think about what they are doing.

    Scrum is set up to be sustainable.

    Not a Death March.

  4. Sorry… no… I would not recommend increasing Sprint lengths.

    My goal of this posting was to differentiate between teams that are on death marches (because they are not pushing back / being transparent) and the Sprint Teams that are effective because they can commit to the work as they see they can handle it.

  5. Dyaneshwaran P says:

    Hi Mike,

    Recently I came across this site and found the cartoon section nice. It’s good that you put a caption above each cartoon. For this article, i have to google about “mouse wheel” and why rats/mice feel excited to run in a wheel for a long time :) Then the picture and write up made more sense to me.

    I have been involved with S/W development using Scrum for 4 years and have waterfall development experience too. At some point while practising scrum, I had this thought — “So in scrum, we have sprint after sprint. So there will be work after work. No time to relax. But in waterfall I will have relaxed time in the early days of IMPLEMENTATION phase.” Forget about the final days of IMPLEMENTAION phase in waterfall world ;)

    The situation still continues. Something is missing here. Always there will be undone tasks in sprint backlog. It goes on and on. I think the focus gets disturbed by new tasks in between. Most importantly we are not celebrating the work done in a sprint !

    For us it is a “mouse wheel” forever. Any comments from you on how to stop it ?

  6. @Dyaneswaran: Some scrum teams take “leap days” between the sprints, i.e. the sprint ends on a Thursday, for example, and starts on Monday, so the Friday can be used to relax, reflect, do other things…

    Furthermore I don’t think that Scrum says you can never have a 1-sprint break e.g. before continuing work, for example after a release – why not?

  7. Meh…

    Remember the team decides what they will commit to during a Sprint. So recall the sustainable pace and do what the team thinks they can do. The regular cadence is a GOOD thing.

    - mike vizdos

Speak Your Mind