How to Double Your Velocity in Sprints?

Girish Subramanian
Oct 23, 2020 · 8 min read

or ‘How to Design and Develop in the same sprint’ or ‘ How to be truly agile’

Design Thinking and Agile break each other. But they need not. Let’s understand the foundations a little better. I will keep them brief.

Design Thinking

Courtesy:

Design thinking framework by the Design Council, UK recommends four distinct phases:

  • Discover. The first diamond helps people understand, rather than simply assume, what the problem is. It involves speaking to and spending time with people who are affected by the issues.
  • Define. The insight gathered from the discovery phase can help you to define the challenge in a different way.
  • Develop. The second diamond encourages people to give different answers to the clearly defined problem, seeking inspiration from elsewhere and co-designing with a range of different people.
  • Deliver. Delivery involves testing out different solutions at small-scale, rejecting those that will not work and improving the ones that will.

Design thinking places importance to Discovery+Definition before Design+Delivery as represented by the Double Diamond

Agile + Scrum

Now let’s look at Agile. I have worked only in a Scrum methodology and I will talk only about that here. But whatever I say also applies to Agile in general.

Courtesy:

Major scrum events that are followed are:

We will focus only on Sprint. The rest are really harmless.

According to the creators of Scrum, each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

Source:

Here is where things start falling apart

Scrum makes an assumption that the design is done and ready before a sprint starts.

Because design needs to be completed before coding, a popular solution is a dual track process.

Development sprint follows Design sprint like a mini waterfall.

Development sprint follows Design sprint like a mini waterfall
Development sprint follows Design sprint like a mini waterfall
Dual Track Scrum

Designers find asking themselves, “How am I supposed to do all the 4 Ds in this time box? Not all problems can be time boxed. We need some time to figure out what the problem, explore, gather insights etc. How do I account for research? Recruitment for user testing? Design iterations? Testing?”

What about Design Sprint? you may ask. It promises one week sprint for co-designing a solution with partners. Design sprint is an amazing framework for aligning different stakeholders on the problem and to validate assumptions with end-users. It’s a discovery framework not a production framework. We will cover Design Sprints later in this article.

Agile is a production framework and it assumes that the Design Sprint is done and the solution is ready to be coded. We are talking about the most impactful way for design to be embedded in dev sprints.

Dual sprint also has efficiency issues. At any given time a designer works on two sprints. Tasks within this design sprint and dev support for tasks done in the previous sprint.

This slows down both design and dev, increases rework and creates bad working relationship between partners because they slow each other down and set each other up for failure.

Expectations vs Reality of the dual track sprints are far apart from each other: (Blue, yellow and green bars represent tasks/stories done in each sprint)

Designers, Developers and QA constantly interrupt each other because they are working on different problems. They slow each other down and set each other up for failure. There is no ‘flow’ between partners.

Discovery vs Production

Not acknowledging that design and design production need to be two different things is the main reason why organizations are not able to find efficiencies in their design operations.

Scrum is a production methodology not a design methodology. But that is not to say that designers cannot work in scrum.

They can. There is a way to do it.

Split Design and Design Production into two streams — Discovery Stream and Production Stream. First two/three Ds from the double diamond happens in the discovery stream and only the last D happens in the Production stream.

But that is not to say that no design happens in production. Tactical design happens in Production and strategic design happens in Discovery.

Discovery Stream

In this stream, teams follow the first three Ds of the double diamond. The designer along with the product owner, design researcher (and in some cases, the developer) co-create the solution. It is a rough + abstract solution to the problem which captures all data points, edge cases, order of flow, some basic interaction design etc.

The designer doesn’t create pixel perfect mocks in this phase but there is a general sense of direction for visual design. This is the perfect time for you to do a Design Sprint. It’s very heavy in logistics and can leave you exhausted if you don’t have a good core team . Seek help from your scrum master and Product Owner to help you with logistics. Seek all the help you can get because Design Sprints are the simplest and quickest way to get alignment on a problem statement and a solution approach. Without these two, dev sprint can become a nightmare.

Alternately, you can be leaner and treat this as ‘refinement’ of your story in a specific format. Basecamp has a great format for this and they call this shape-up. At the end of shape up they create a refined requirement called as a . You may choose to devise your own format based on your context.

In this phase, you may also create wireframes and get tested it with your users. The goal is to determine the functional design of the product/feature along with its dependencies and constraints before it can be coded.(again, not pixel perfect mocks)

This needs to be co-created with your partners. (This is crucial for velocity)

Here is an example of how this may look. I have used ‘enhancement for filters’ as an example to keep this simple. But it can extend further to more complex flows.

whiteboard sketch of a data filter with data points and behaviours
whiteboard sketch of a data filter with data points and behaviours
Shaped up by the PO, Design Lead, Dev Lead, QA Lead and A11Y specialist
screenshot of a document that describes the filter behaviour
screenshot of a document that describes the filter behaviour
Partial screenshot of a pitch co-written by PO, Design Lead, Dev Lead, QA Lead and A11Y specialist

Production Stream

Based on the solution agreed during the discovery phase, the PO, designer, developer, QA and A11Y expert (and other relevant players) enter the sprint.

Because visual design and development are happening simultaneously, a lot of back and forth is avoided between the teams and it increases the velocity of the teams many fold.

No more working in two sprints at the same time. All partners are working on the same problem during the sprint. Every decision between the partners is taken as a group during the sprint.

No more final reviews and feedback and rework and all that headache and heartache.

Here is a partial screenshot of a chat between a designer, developer and the A11Y expert:

screenshot of chat between designer, developer and accessibility expert discussing potential solutions for a problem
screenshot of chat between designer, developer and accessibility expert discussing potential solutions for a problem
Screenshot of a designer, developer and A11Y expert ‘co-located’ digitally

The team co-locates and co-builds within a sprint and they design and develop simultaneously. Because most visual design decisions are captured in design guidelines and/or the Design Systems, the designer and developer are able co-build the solution together.

Designer and developer share progress every day and conduct daily demos to each other and because of this a lot of visual design fine tuning happens on front end code. The designer immediately updates the mocks to reflect these changes.

This is how the filters ended up looking. Not bad, huh?

Final version of filter after co-design and co-build
Final version of filter after co-design and co-build
Finished version of designed and coded filters

In effect, the whole process looks like this now:

Improved Dual Track
Discovery track is separate from the Production track. UI design and development happen in same sprint during production.
Discovery track is separate from the Production track. UI design and development happen in same sprint during production.
A better reality is when Discovery and Production are separated and UI+Dev happens in same sprint

I have been experimenting with this model with great success for more than 15 months now. The velocity of the team has almost doubled. What used to take almost 2 sprints now takes only one sprint. It is nothing less than a miracle.

Explore+Shape up first. Build+Iterate later

However, there are some preconditions for this to happen

  • Everyone involved needs to be courageous to experiment — Scrum master, PO, Designer, Developer, QA and other partners
  • Only teams with mutual respect and curiosity can do this. Warring factions will never achieve this agile nirvana. (Don’t even try this if your PO, designer and developer can’t see eye to eye)
  • There should be NO APPROVALS or SIGN OFFS. The teams should be empowered to take decisions and own the risks. Any feedback from leads and management should happen after the sprint and should be taken up as enhancement or bug. The team should be left alone with zero supervision. This is MANDATORY. (Let them do their job. If you don’t trust them, replace them. Just don’t hover over them)
  • No scope creep after a pitch is written. Any new requirement or idea should be added as an enhancement (same as agile)
  • Read this . Multiple times. Ask your team to read this. Multiple times. Read till the spirit of ‘shape up’ becomes a natural way of thinking for you.

A huge thanks to for writing all this down in this . Thanks to for making me read this(multiple times). Thanks to , , , , , , , and the entire dev + QA team for making this theory into practice. Thanks all 🙏🏾

If you are curious to know more details about how we managed to accomplish this and want to replicate this, reach out to me on Happy to chat and spread the message.

Geek Culture

Proud to geek out.

Sign up for Geek Culture Hits

By Geek Culture

Subscribe to receive top 10 most read stories of Geek Culture — delivered straight into your inbox, once a week. 

By signing up, you will create a Medium account if you don’t already have one. Review our for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Geek Culture

A new tech publication by Start it up (https://medium.com/swlh).

Girish Subramanian

Written by

Object Maker. Experience Collector. Story Seeker. Wikipedia Glutton. Happy Sleeper.

Geek Culture

A new tech publication by Start it up (https://medium.com/swlh).

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface.

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox.

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store