The sprint is the basic unit of productive time in Scrum. According to the official Scrum Guide (2017 version), the sprint is “the heart” of Scrum, a period of less than one month during which teams commit to and complete usable pieces of functionality. The sprint is the container for everything else – planning, working, reviewing product and process.

Sprints are valuable constraints in any type of knowledge work. Scrum was created to help software teams accomplish more work on a regular basis rather than dawdling until right before the release date. The sprint is frame within that work is done.

Should Agile Faculty sprint? Totally up to you.

I honestly go back and forth on it. When I do sprint, it’s usually in 2-3 week timeboxes, such as the three-week window I used this January for my writing challenge. Pre-sprint, I chose a couple of things to focus on completely during that time, set up my Scrum board with only those projects, and tried to focus on the work I had committed to (results were mix as you’ll see in the post).

When I’m not sprinting, I’m still being Agile and using my Scrum board; my goals are still prioritized and I use them to guide my work, but I don’t timebox it. I just plan, execute, and reflect regularly instead of in a two-week period. This is closer to Kanban, which you can learn more about here and in this Book Club post I wrote about Dominica DeGrandis’s recent book, Making Work Visible.

Personally, I find that I don’t need to sprint to be productive in meeting my goals, but it helps if I’m working with a group because we can time our work and meetings according to a sprint cycle. Sprinting also becomes useful when I find I’m not making progress without the accountability. So I might bring a colleague in, talk about what I’m going to accomplish in two weeks, and then schedule a meeting with that peer to meet for extra accountability.

Do you sprint or go with the Kanban flow? What works best for you, and why?