Get certified - Transform your world of work today

Close

What Are Design Sprints and How Do They Work?

How good design and Scrum are stronger together

11 September 2017

Jason Moccia
OneSpring LLC


If you haven’t heard about design sprints before, this is a great place to start. Design sprints enable business teams to use the same processes and terminology that IT teams use with Agile and, specifically, Scrum. The goal of design sprints is to foster better communication between business and IT by creating parallel processes that complement one another. In my 2012 article, “Agile Requirements Definition and Management,” I described one possible solution to the communication issue and how Scrum can be leveraged seamlessly across the organization and not just IT. Over the years, the process has evolved into the design sprint, which is addressed in this article. The goal here is to introduce you to the concepts and to lay the groundwork for enhancing an already successful process — Agile/Scrum.
 

The role of the product owner

Although there are many benefits to Scrum, there are still opportunities to improve the process. Scrum is an IT-centric software development approach. As a result, it does not clearly consider business environments and how needs are organized and communicated top down. To help combat this gap, the Scrum process points to the role of the product owner. This role represents the business needs and goals within a Scrum project. The product owner is responsible for determining what is being built, its acceptance criteria, and its prioritization. There is a tremendous responsibility on behalf of the product owner to continuously "groom" the product backlog to ensure that the development team has sufficiently prioritized work in each sprint. In addition, the product owner must be available throughout the sprint to help clarify questions as they surface.

In our experience, the product owner is typically not dedicated to the Scrum team and therefore rarely has the time to fulfill these responsibilities. As a result, the quality of work may diminish, causing spikes in the sprint that lead to rework. In a worst-case scenario, the project is completed, but not successfully, because what has been built still does not meet the expectations and needs of the business. Many organizations that have attempted to become Agile and still have project failures usually have experienced this cycle firsthand. We have observed that Agile helps increase the speed of output but does not guarantee that the output will meet the business needs of a complex organization. Let us look at a simple example by contrasting Scrum with other industry processes.
 

Industry processes

In most product development industries outside of software, the business has greater support and ability to plan the design of what to build prior to starting the development or build process. For example, if you want to build a house, you would most likely meet with an architect and spend time up front, visualizing the design of your house based on your family needs, desires, and ideal lifestyle (e.g., room layout and flow, windows, and dimensions). Then you bid out the work to a builder/developer who relies on the architectural plans to produce the house. As the homeowner, you continue to be involved throughout as changes occur and decisions are made. The architect is consulted throughout the project to make sure the design stays true to the original intent.

Over many decades, this process has been proven to work. The primary change that has occurred over the past several years is that the technology used to produce architectural blueprints and designs has gotten much more sophisticated. For example, technology has made it more transparent, faster, and cheaper to produce designs. These advancements are just as relevant to the software industry as they are to the construction industry. Scrum is all about iterative development that allows teams to produce working code faster and in smaller portions to help drive user engagement and increased transparency.

Even though the construction process mentioned is similar to software development, there are some key differences worth pointing out. First, the process to build a house is design focused, not textually based. Initial designs are sketched on paper, then translated to Computer Aided Design software later to identify specific measurements and constraints. The homeowner gets to see and experience the design and work out as many issues as possible prior to beginning construction. If the homeowner were to try to do this directly with the builder on site, the cost would be exceedingly high in terms of time and money. The need for rework would inevitably drive up the cost, and the homeowner would end up with a finished product that would most likely miss the original intent or vision. This is precisely why a large portion of time is spent up front designing and planning what needs to be built.
 

Gaining insight into user needs

The lesson from all of this is that the more time spent up front fine-tuning the design, the smoother the development process. This same premise holds true for software development projects. In a Scrum model, developers rely on user stories to flesh out user needs, which are primarily written by product owners or business analysts. I won’t delve into all aspects of user story techniques in this article, but I want to at least review the approach.

The issue with user stories is that they are based on myopic views of the system. In the house construction example, it’s like telling the architect how the kitchen utensil drawer should work before there is a shared understanding of a room in the house called the kitchen, where the utensil drawer would reside. To gain better insights, we have to move up a level to view all aspects of the software application in a single and holistic view. Scrum attempts to do this through the concept called epics; however, it is still difficult to clearly articulate and understand the business needs based on this high-level view. In construction, you can see and touch the plans, which drive user engagement. You can visualize how people will flow through the house and how it will be lived in on a daily basis. The process of engagement is as critical to construction as it is for software projects.

In software development, user research and usability studies are employed to help facilitate this, but they are sometimes injected too late in the process. In Scrum, the intent is to break apart development into smaller portions so that IT can test early and often, to gain insights and validate user needs. In our opinion, this discovery should happen much earlier in the design phase. Therefore, this led us to evolve and enhance the process by using the design sprint.
 

Example: GV’s design sprint

The most notable organization using this technique is GV (formerly Google Ventures). Their challenge was finding an effective and quick way to help validate business ideas and promote business decision making for their portfolio. The design sprint was created, tested, and proven in more than 100 sprints with various businesses. The key value the design sprint provided was the ability for teams to learn and validate their business ideas without expending time or money on building and launching a coded product first.

Figure 1. “The sprint gives teams a short-cut to learning without building and launching.” - GV

GV’s design sprint focuses on a five-day session, primarily used to validate ideas. This is great for high-profile, quick-hit concepts, but what about longer-term, complex systems? To account for this, we have adapted and enhanced the design sprint concept to better fit into complex organizational environments. Regardless of the sprint variations, the core tenets of the design sprint are the same. The goal is to perform a timeboxed design effort to flesh out software details using the latest in design techniques while increasing user engagement and adoption. For example, rapid prototyping and visualizations can be used to gain insights into the design and how software should function prior to development. The primary benefits include consensus-building between business and IT, adoption of Agile across the organization, and reduced rework.


Figure 2. The design sprint
 

Increasing user engagement

More articles will be released on these concepts over the coming weeks, but let me touch on one of the benefits now. Adopting Agile across the organization is one of the more challenging components most organizations face because Scrum is an IT-centric approach, which in many cases ignores the integration of business and cultural standards and norms. For an organization to successfully adopt Agile, it must consider how other areas of the organization may be impacted. Design sprints are inherently more business-side focused because the fundamental tenets are based on determining user needs and increasing engagement. If you think of user engagement as a model along with development time, the graph would look something like what is outlined in Figure 3.0.
 

Figure 3. User engagement versus development time

As user engagement increases, development time decreases. This applies also to the home construction example, to a limit. However, you can drive down development time by only so much before quality suffers. You must consider the law of diminishing returns when adding more resources to a project. Therefore, the intent is to strike equilibrium between too much user engagement and too many developers. Excess user engagement can lead to analysis delays and overthinking. Design sprints are meant to establish this equilibrium and to increase Agile adoption by creating a common language and procedures across the organization.

Design sprints incorporate the same language and procedures as development sprints. The difference between the two types of sprints is the outputs. For example, in a design sprint, an output may be vetted through user stories or screen mock-ups, whereas in a development sprint, the output is finished code. The goal is to create parallel procedures using the same language and practices aimed at establishing standard processes at the business and IT levels. In time, this helps educate IT and non-IT participants, which leads to greater understanding and productive, habit-forming behaviors.

This is the first in a series of articles aimed at educating users on the merits of design sprints and how your organization may be able to leverage some of these insights to be more successful.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 1.9 (11 ratings)

Comments

Janice Cullivan, CSM, 9/14/2017 7:01:49 PM
Great article but the images aren't rendering.
Jason Moccia, CSM, 9/15/2017 11:18:07 AM
Thanks. I mentioned this to Scrum Alliance and they're trying to fix the image issue. Not sure why they're not showing up.
Jason Moccia, CSM, 9/15/2017 11:34:02 AM
Thanks. I mentioned this to Scrum Alliance and they're trying to fix the image issue. Not sure why they're not showing up.
Michael James, CST,CSP,CSM,CSPO,REP, 9/17/2017 2:27:08 AM
There is nothing new about the debate between waterfall, agile, and waterfall/agile hybrids. The new part is the way waterfall and hybrid methods disguise themselves as Scrum/agile. A Sprint is *a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.* ( http://scrumguides.org/scrum-guide.html#events-sprint ) One may make reasonable arguments in favor of waterfall/agile hybrids, but it's not helpful to spread confusion about the definition of Scrum.
Michael James, CST,CSP,CSM,CSPO,REP, 9/17/2017 4:53:59 PM
After reflection and discussion with a few of my friends, I regret the tone of my response above.
Tim Baffa, CSM, 10/9/2017 4:48:53 PM
Michael, you may have been more empathetic in your response in hindsight, but your content was spot on.

The "watering down" of Scrum to represent the various phases of waterfall is quite insidious and potentially damaging to Scrum. We should feel empowered to point out such misrepresentations of Scrum.
Jason Moccia, CSM, 10/17/2017 10:51:57 AM
Thanks for the feedback. It's important to point out that Design Sprints are not masquerading as Waterfall in any way. They are highly iterative segments of work which in many cases run in parallel to Development Sprints. It's also important to consider the process of adoption of Agile within large organizations and how best to integrate business needs/goals with IT. Although Design Sprints leverage similar practices as Development Sprints, the output is entirely different. The goal of doing Design Sprints is to help development by creating parallel value streams. On one hand the focus is on eliciting needs through the use of market research, user experience, rapid prototyping, and analytics which culminates into meaningful and validated material in which development can utilize to build better products. Typically, development pushes back on this because of what was pointed out in the comments, however, the process of working with business owners to gather and effectively communicate what is required and accurate to build from is in itself a complicated endeavor. The resistances of the use of similar nomenclature should not be a barrier to driving increased value and adoption.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe