Design Sprints

Probably the Gold Standard for design sprints is Ideo's Design Kit: The Field Guide to Human-Centered Design. The problem is that these are large, complex beasts and small companies generally won't have the resources to conduct them. (If you do, then go for it!)

Google Ventures Design Sprint (GVDS)

A derivative of this process is the Google Ventures Design Sprint. This process follows a five-day arc led by a designer/facilitator and commanded by a product owner.

Stage Activity Theme
Pre-Sprint Set the stage Prep
Monday Create a framework for the sprint Understand
Tuesday Summarize existing solutions, sketch new solutions Diverge
Wednesday Critique new solutions, narrow the focus, storyboard one Converge
Thursday: Create a works-like/looks-like prototype (Keynote, sketches, foam, paper, etc.) Prototype
Friday Test the prototype with real users. Test & Learn

The good thing about the GVDS process is that it's not democratic. The product owner ultimately makes the call on decisions, and that's good because it tends to focus the effort on fewer ideas of better quality.

Everyday Sprints

For a small company it might be hard to find the resources entire teams to regularly spend a week to run GVDS process. Since there will be tons of continuous design choices along the entire product gradient, you want to make sure the most important decisions come from a careful, measured process. For this reason we invented the "Everyday Sprint" that teams could run regularly with low burden. Typically we follow these steps:

At the end of the design sprint, the sprint leader and product (or feature) owner should have a complete set of design stories categorized by how essential they are to the user process under consideration. These stories get entered into the tracking system (e.g. Jira) for the development team to slot into developer sprints. Because you've taught the development team good design practices, it's both safe and rewarding to allow them to run development from the design stories alone. (Most developer teams will likely first generate user stories and detailed specifications from the design stories.) The good thing about this process is that it's not prescriptive - design stories states what's needful and gives the developer wide intellectual latitude to come up with the best solution.