Why I choose weekly sprints for my own projects

This week I don’t have a solid retro — I’m putting together a brand spanking new website, and I’m going to spend some time putting together content for the site before I launch it to the public. In the meantime I figured I would put together a post regarding what my development cycle usually looks like when I’m working on my own projects.

—–

My first development job was at Wunderman working on Best Buy’s weekly deals site. Every Monday I would come into work sit down and get a list of 10 – 20 custom development widgets that I would have to crank out by Friday. I was the only developer on the production team, and even more surprising the only developer in the entire Minneapolis branch of the agency. The production team was on a quick weekly turn-around.

Weekly turn-arounds don’t account for things called “Best-practices” the first time around.

Fortunately at Wunderman I was able to build off of each week, and while the first couple of weeks had some extremely tight deadlines, I was able to build off of the previous week which allowed me to complete the work in a fraction of the amount of time. Eventually when I left Wunderman I had automated a large chunk of the work I was doing.

Before the concept of Google Design Sprints had received main stream traction I was running a version of my own.

How I choose my sprint duration?

Sprint duration is always a touchy topic. One, Two, Three…Four?! Every organization has a different idea of what the ideal duration is to build a chunk of work. None of these organizations are wrong, but sometimes it’s hard for a team of producers ( developers, designers, user experience, content ) when each of the projects have a different cadence.

This is also a challenge for the organizations when asking themselves what is the volume of work that they can produce, because the measuring sticks are never the same.

So what measuring stick do I use for myself?

Three weeks is too long for my own uses. I’ve seen it benefit teams that are transitioning from Waterfall practices, and do not have the DevOps support that they need — so the developers who are building the product also need to estimate deployment activities every sprint — which cuts into actual build time.

Two weeks is about the right time, but what ends up happening is my weekly rituals are never the same — so it’s harder for me to get into a long-term groove. In addition the type of work that you can complete in two weeks can be fairly large — and for myself completing a larger amount of work allows me to think that I have earned some “downtime”

One week increments of work is my sweet spot. I’ve been formed by it in my career — working within Google Design Sprints and just the way that I worked at Best Buy and U.S. Bank.

Slicing things out into one week increments also allows for better work habits. I do the same thing every week so I can confidently select what work that I can successfully build in a week.

What do my weekly rituals look like?

Monday:

  1. Decide how many hours I want to dedicate for the week.
  2. Look at my list of priorities and decide what I could finish in a week in addition to what would provide the most value.
  3. If prioritized work includes development and new user interface work: start a mini design session. Usually leveraging Post It notes and finishing in a Codepen.
  4. If prioritized work includes development that has new functionality that I haven’t built before: start a mini research session where I create a functional prototype.
  5. If prioritized work includes content, create a rough draft and a rough timeline of when the items will be published

The important part of Monday with week long sprints is to understand the work that I’ll be finishing over the rest of the week. If there’s an item that gets revealed during the design / research sessions than I’ll prioritize it in a later sprint. This allows me to keep it in the back of my mind and mull it over when I’m biking or doing something else.

Tuesday:

  1. Finish design or content exercise.
  2. Start bulk of the work for the week.

Tuesday is the real preparation day for the rest of the week. For example, usually I have most of the User Interface roughed out — all the divs and classes are in place but things may not be responsive.

Wednesday:

  1. Continue work.

Wednesday is the day that I get the bulk of the work done — prioritizing functionality over micro interactions. If I’ve done everything right at the end of the day I will have a good idea if I will be able to complete the main value proposition.

Thursday

  1. Finish core of work.
  2. Take a look at the existing backlog and determine if there are any quick wins that I could add to the weeks feature set.
  3. Take a look at the weeks work and make any final cosmetic touches or add microinteractions.

Friday

  1. Double check Quality / Accessibility / Performance
  2. Deploy!

One thing that you may note about the above is that there usually isn’t any steps for “Review” — that’s because when I’m working with partners they always have access to what I’m working on, either by having access to my git repo or if we’re on the same network they usually have access to my localhost site.

And there you have it! What my week looks like as of August 2018. My weekly ritual has been continuously updated over the years, and I’m sure that it will continue to be updated in the future as I start leaning more heavily into content driven work.

About the Author

Headshot of Mathias Rechtzigel with some sweet lazers in the background. Like the type you would find in a cheesy Sears photoshoot. Yeah those ones.

Mathias Rechtzigel is a web creator, his skills range from development, design, user experience and sometimes content creation.

He lives in Minneapolis, Minnesota with his partner (Ellen), dog (Bard), and two cats ( Pippi & Misti ).

Connect with me on

Join me on my journey

Sign up and I'll send you a weekly email with links to my posts, and other valuable links that I find througout the week.