Why there’s no one-size-fits-all when it comes to sprint cycles

Profile picture of Coren Feldman

{date}

{#hash1}

{#hash2}

Illustrations by {name}

What works for one team may not work well for another. With openness and flexibility, each company can find their ideal workflow.

8 min read

Photo of three people talking in an office

Stay informed on all things design.

Thanks for submitting!

Shaping Design is created on Editor X, the advanced web design platform for professionals. Create your next project on Editor X. 

Get our latest stories delivered straight to your inbox →

When a startup is at the beginning of its journey and has a core team of just a handful of people, it’s easy to simply work on issues as they come up. However, as the company expands, it quickly becomes clear that the same approach will not be viable moving forward.


It’s at this juncture in a startup’s life that you might find yourself asking: How do we create a workflow that will allow our team to work together more efficiently?


Jonathan Caras, a serial entrepreneur who’s managed over a dozen teams, always focuses on creating a workflow that works for everyone: “What kills a good project is often times the system creates so much friction that the employees end up tuning out, and that's where you're guaranteed to take a good product and turn it into a bad product over time.”


It’s important to approach this process with an open mind, even if you have experience managing sprint cycles for other companies. Systems that work for one team don’t necessarily work for another. Many different factors can contribute to determining what makes the most sense for your team. What type of product you’re building, the company departments, and team size can all make or break a system.


However, if you pay close attention to your team and are open to a little trial and error, you can find the workflow that fits just right.



Agile? Scrum? Waterfall?


There are a lot of different methodologies companies use to manage their workflows, and product managers have strong beliefs about which is best. Each methodology focuses on a different aspect of the process. The two most used methodologies are:


  • Waterfall - An older process that creates a rigid hierarchical structure that’s easy to track and manage. It makes sure that each team has everything it needs in order to hand off to the next team to start their work.

  • Scrum - A popular implementation of the Agile methodology. Agile is a manifesto that values interactions, collaboration, and flexibility over planning and detailed specifications. Scrum uses feature-based teams rather than traditional departments in order to build faster. Each team is composed of a product manager, Scrum Master, and the other team members it needs for its purposes.



Four team members in a meeting


Both of these approaches have their benefits and shortcomings. Waterfall prioritizes structure over teamwork and can make departments feel like black boxes. Scrum can make it hard to have an overview of the product for members in feature teams (especially UX designers). Ultimately, you know your team best, and you should find what works for them.


Few companies adhere to the exact rules of these workflows. Waterfall-based companies sometimes run stand-up meetings, and agile workflows can include more formal design meetings with multiple stakeholders.


Don’t feel pigeonholed by what is essentially a template created by someone who has never met the people you’re working with. Whether you want to strictly adhere to these workflows or not is entirely your choice.


When you identify what your organization’s objectives are, you can work backwards from there in order to figure out sprint features and length.

“Which methodology you have is less important–at least from what I've found– than having a consistent methodology you can funnel creative thought into,” Caras says.


Whatever you’re leaning towards, these components are commonly used and should be considered for your workflow:


  • Daily stand-ups (or scrums) –– Holding team, or company wide, stand-up meetings allows everyone to be in sync regarding where the company is holding and feel like they are a part of something bigger. This is also a good opportunity to gauge team members’ progress on their tasks and make sure they’re not being blocked by anything. You’d be surprised at how much people won’t tell you if you don’t prompt them. Just make sure this is a judgement-free, calm space. True to its name, it’s a good idea to have everyone stand up while this meeting is happening to ensure that it’s quick. No one wants to stand–or be at this meeting–for longer than 10 to 15 minutes.

  • Design sprints –– This is a special type of sprint designed by Google that lives outside of the normal sprint cycle. The design sprint is a five-day process that helps solve large, important challenges your company is facing. Using a cross-department team, you identify issues, prototype, and test your designs, which allows you to make sure you’ve come up with the right solution before you make a big change. It’s a very effective method to quickly solve big problems when used right. Just keep in mind that running a design sprint is resource intensive, and it shouldn’t be a go-to for any design challenge.

  • Sprint naming –– This might seem a little silly, but giving your sprints names instead of numbers makes them feel more exciting. You can decide on a naming convention–for example, celestial objects–and go through the alphabet. It’s a lot easier to look forward to working on Version Pluto than on v2.3.1. You should still append a number to these, just so it’s easier to keep track.

  • Feedback loops –– After each sprint (or whatever period of time is relevant), show your team the impact their effort has made, using analytics or user testimonials. Feeling that what they’re doing is actually moving the needle on your company’s goals or changing your user’s lives creates a sense of reward, comradery, and a determination to continue moving forward.

  • Q and A hour –– If you can, having a company-wide Q and A hour at the end of a sprint will allow you to find and fix bugs faster, with the added benefit of giving everyone a quick breather from what they were working on. Having everyone working together on it is both effective and fun as it brings the whole team together, focused on a common goal.



A group of team members in a meeting


Design review meetings


Holding different review meetings for features helps refine the specifications and align expectations. You may decide you want to forego certain types of meetings or not have any of them. It depends entirely on what works for you.


That being said, these meetings can be very helpful and, if executed correctly, can save on work time later by avoiding back and forths over small details: