Let's set the scene. You're a fearless founder who's trying to run the lead while bridging the gap between design and development. It's end of year and you have deadlines to meet, investors to answer to. They want your MVP launched yesterday and you're pressed for time managing all of your priorities.
We've heard this story all too many times with questions on how to effectively manage your teams and set milestones to reach your next round of funding. Behold the power of the sprint! Not familiar? We promise it'll become your best friend. We're here to break down the sprint mystique.
According to TechTarget, a sprint in its most basic form is the process that sets a period of time for work to be completed. Sprints put your entire team on the same rhythmic cadence. Your team knows what each person's responsibility is and the expected length of time to complete specific tasks.
After you've gone through the process of completing your business strategy, UX+UI, and requirements document, it's now time to turn over everything to your development team. They'll be best able to assess how long each task should take. Remember, these are approximations and can (sometimes) take longer depending on some outlier obstacles they may face. Get a rough time estimate with a sprint breakdown. Each sprint will show what features are being built and what review is taking place.
Each sprint is broken down into two: new features and bug review. Your dev team should be making continual progress each week in new build features. There should also be time reserved each week to go through tasks that are called considered "bugs" - things that aren't working properly or were designed an incorrect way.
Set goals and objectives for the sprint process. You may be launching your v1.0 or experimenting with new features. These have very different success metrics. Remember to keep in mind your end user! How will this work pay off for the end user?
Sprints are typically determined by someone called a "scrum master," or the person who is leading the development process. If you're a solo founder and haven't hired a product manager, by default you may now be the scrum master too.
In our experience, sprints run anywhere between 1-2 weeks. Larger organizations tend to run on longer sprints (sometimes as long as 4 weeks for bigger tasks), but since we're startup focused, we're looking for quick, incremental turnarounds. It's important to include the time that's needed for meeting prep, new product demos, and issue spotting.
You may have over-designed your MVP. Go back and review what features you're including and whether they have a direct correlation to your first launch success. Your MVP is meant to prove an assumption. If there's extra "nice-to-haves," put them in a backlog. You may actually come to learn that you never needed those extra features after all.
We're huge fans of Trello, Asana, and Slack ourselves. It's important to use a platform that everyone uses on everyday. From Trello or Asana, you'll be able to invite your team members and most importantly, tag them to the tasks (and deadlines) they're responsible for. If you have questions for your team throughout the process, no worries. These platforms give you the ability to document all notes, clarifications, and changes within their card-style structure. If there's something that needs a quick dive, use Slack but make sure you document any changes in their respective cards.
There are tons of management platforms out there but their functionality remains the same during the sprint process. When you first start development, create columns in your platform of choice to guide your team through the sprint process. With the ability of creating new cards, set a format of what is required from all when they spot a bug. Outline the following:
Schedule all meetings in advance and give a couple of days buffer just in case something goes wrong. Tech is ever evolving and there may be something that comes up that you weren't expecting. Be mindful of holidays and vacations along the way.
Keep in mind that it's an agile process meaning that each sprint will move quickly. You may find yourself pivoting and adapting to unknown factors along the way.
According to Scrum.org, "An unsuccessful Sprint is one where at the end we have not learned anything."
I've gone through countless sprints and know what to look out for. If you're a founder that needs help to get you across that finish line, send an email! I love working with founders to help them reach their next milestone.
