Now that you’ve figured out what to build and why, it’s time to move from prioritization into execution. In synchronized delivery, design plays the lead role—but not in the diva kind of way. Your UX team sets the pace for development, working just ahead of engineering so that by the time dev is ready to build, the designs are already baked, blessed, and ready for handoff. This staggered structure keeps both teams in motion without stepping on each other’s toes.

But—and this is important—staying ahead of development doesn’t mean racing ahead into the sunset and leaving the dev team in the dust. Design needs to be aligned with the product vision, the prioritized initiatives, and the technical realities of the team that will ultimately build what you create. Otherwise, you’re not so much leading as drifting off on another path altogether. 

As I mentioned in the previous chapter, I used to treat design like a separate phase: something you finish before development even begins. But that never worked. Designs get stale. Requirements change. And worst of all, the development team felt like they were inheriting a pile of over-baked ideas instead of building from a shared source of truth.

But we live and learn. Now, design is structured into its own sprint cycle—fully aligned to the same priorities, but decoupled from development’s timeline. This gives designers the space to explore, iterate, and test without slowing things down or triggering unnecessary rework. 

In this chapter, I’ll walk you through how to:

  • Break down initiatives into design epics, issues, and tasks
  • Estimate design effort and avoid overcommitting
  • Plan sprints that keep designers focused and productive
  • Stay exactly one sprint ahead of development
  • Coordinate handoffs without chaos or surprise changes

We have a lot to cover, so let’s get started. 

Getting Ready

I know you’re itching to finally turn your flowchart into full-fledged screens, but a little prep beforehand goes a long way. Synchronized delivery works only when design, business, and development all start on the same page—literally and figuratively. Before you start outlining design sprints, let’s get ready for this phase of Blueprint Agile. 

Gather Your Documents

That’s right, it’s finally time to put your Entity Relationship Blueprint (ERB), Information Architecture Blueprint (IAB), and user flowchart to the test. Together these documents spell out what your product is, how it’s structured, and how people move through it. Drop the latest versions in a shared drive or FigJam board, pin them in Slack—whatever it takes to make sure everyone on the team can get to them without asking. When questions pop up mid‑sprint, these docs are your single source of truth.

Stick Together

Design may be leading the parade, but you won’t be marching alone. What design does in their design sprints has a direct impact downstream on the dev tem. So to intercept issues early, invite a dev lead to your design sprint reviews, and have a designer sit in on backlog grooming. A five‑minute chat up front saves a week of “small tweaks” later. Keep a shared channel open with business stakeholders, too. Everybody should have visibility into the progress of the other team. 

You Kanban Do It

Once you start organizing work into tickets and planning sprints, the right tools make all the difference. Project management software like Jira, Trello, Linear, or whatever your team swears by will help you stay organized and track your progress. Set up a kanban board with swimlanes that reflect your design workflow, use Epics, Issues, and Tasks to structure your work within each stage. Your future-self will thank your past-self for setting up and maintaining a kanban board. 

The Process

Now, it’s finally time to take the initiatives you prioritized in the previous chapter and transform them into actionable design sprints. Then, you’ll turn these sprints into real-world designs! Here’s how the process looks: 

Step 1: Break Down Initiatives into Design Epics, Issues, and Tasks

First, you’ll translate each initiative into specific, executable units of design work. You’ll break your work down into epics (big, outcome-based chunks), issues (specific design deliverables), and tasks (granular to-dos). Each item should map back to your user flows and be independently actionable.

Step 2: Estimate Design Effort

Once your issues are defined, your next task is to assign time estimates to help balance workloads and plan realistic sprints. Knowing roughly how long each piece will take allows you to avoid overloading designers and build a sustainable rhythm.

Step 3: Plan Design Sprints

With your work mapped and estimated, the next step is to organize it into focused, two-week sprints. This is where you decide which issues will go where, factoring in priority, dependencies, and available capacity. 

Step 4: Parallel Delivery

Once sprints are underway, design and development teams will work in tandem. In this phase, you’ll learn how the design team should groom tickets, kick off new sprints, conduct 60% reviews, and hold end-of-sprint demos and handoffs.

Synchronized delivery will last several months, but when all of the sprints are completed, you should have a complete first iteration of your application. 

Step 1: Break Down Initiatives into Design Epics, Issues, and Tasks

It’s time to turn your initiatives into actionable work within a structured timeline. In this step, you’ll be organizing and assigning tasks into sprints in a way that maximizes productivity, keeps design and development teams aligned, and ensures steady progress. Taking the time now to thoughtfully plan sprints out will pay off later on, bringing order to the implementation process and preventing the chaos that invariably arises in complex projects. 

A sprint typically spans two weeks of focused work on a specific set of tasks, though some teams may adjust the duration to suit their needs. Each sprint should be guided by a clear, achievable goal that directly aligns with your prioritized initiatives.

To break down each initiative, we use a hierarchy of work units, starting with epics. An epic represents a large body of work that aligns with a major milestone or feature, often spanning multiple sprints. It encapsulates a complete goal within the initiative but still needs further refinement to be actionable. Each initiative will be broken down into one or more epics.

When naming your epics, aim to clearly communicate their scope and purpose. Avoid vague or overly long names, and ensure each name is distinctive from other epics. Focus on the outcome or goal, rather than simply restating the problem. For example, if your initiative is “Improve the onboarding process for users,” an epic might be “User Onboarding Experience Redesign.” 

Each epic can then be divided into issues, which are specific work items focused on distinct parts of the epic. An issue represents a clear objective within the epic, often completing a specific aspect of the feature or milestone. Issues for the epic, “User Onboarding Experience Redesign,” might include “Add Profile Setup,” “Optimize Onboarding Flow for Mobile,” and “Create First-Time Offer.” Each issue should be well-defined and small enough to be completed within one sprint. 

Tasks are the most granular level of work. Each issue can be broken down into one or more tasks, which represent the specific actions or steps necessary to complete the issue. Tasks should be simple and actionable. For example, if the issue is “Optimize Onboarding Flow for Mobile,” your tasks could be “adapt designs for responsive layouts” or “test onboarding flow on various screen sizes.” Typically, tasks are short enough to be completed within a few hours to a single day. 

Using project management software, such as Jira, can be especially helpful during this step for helping you organize sprints, assign responsibilities, and track progress at every level. 

1.1. Define Design Epics

For each initiative, identify what achieving it will look like and the major milestones that will get you there. Each milestone will typically align with an epic. Epics should be significant but feasible within one to two months. If an epic is too large to complete within this timeframe, it may need to be divided into multiple epics to keep work manageable and progress visible.

Each epic should:

  • Have a clear, descriptive name that focuses on the outcome.
  • Capture a complete outcome, not just a loose collection of ideas.
  • Describe a user-facing result or milestone you’re trying to achieve (not just the problem)
  • Not be too big, or too small. 
  • Be mappable to a specific section of your user flowchart. 
  • Include acceptance criteria. 

1.2. Break Epics into Issues

Once you’ve laid out your epics, you can start breaking them out into issues. Each issue should represent a specific part of the functionality within an epic. Where possible, issues should be self-contained, allowing the team to work on multiple issues in parallel and avoid bottlenecks. Issues should also be completable within one sprint. If that’s not possible, divide it up further. 

Each issue should: 

  • Be tightly focused on one screen, flow, or component set.
  • Not overlap multiple areas of the application. 
  • Tie back to an epic.
  • Have a clear, descriptive name. 
  • Result in a concrete design output that can be reviewed or handed off to development.
  • Include a rough estimate (in hours, days, or story points) so it can be realistically scheduled within a sprint.
  • Include acceptance criteria. 

1.3. Break Issues into Tasks (If Needed)

Within issues, you may choose to create simple, bite-sized tasks. Ideally, tasks should only take less than a day to complete. Tasks that take longer may need to be broken down further. While epics and issues should be planned out in advance for the most part, you may decide to wait until ticket grooming sessions to define tasks for each issue. This gives you the flexibility to incorporate feedback or adapt to evolving requirements.

Step 2: Estimate Design Effort

Once your epics and issues are clearly identified, it’s time to assign time estimates to each issue. Estimation is crucial because it lets you realistically gauge how much work can fit into each sprint, prevents overloading, and ensures that your team has clear, achievable targets. 

Remember, estimates are just that. The objective here is to aim for a 20% margin of error, providing enough accuracy to support effective planning without overcommitting resources. When everyone has the benefit of referring back to the discovery documentation you’ve created, they’ll have a more accurate sense of the level of effort each issue demands. 

2.1. Choose a Consistent Measurement

For time estimates, it’s essential to use a standard measurement that your team is familiar with, whether that’s hours, story points, or another method that works for your team. You can also use a more creative system of measurement, such as shirt sizes—XS, S, M, L, XL—for estimating. Each issue should be estimated by the designer responsible for completing it, as they’ll obviously have the clearest perspective on the complexity involved. 

2.2. Use Reference Points and Data

Don’t estimate in a vacuum. Use your discovery documentation (ERB, IAB, user flows) and past projects as benchmarks. At Brandcave, for instance, time estimates for a senior UX designer usually follow these guidelines:  

  • List Views: Typically take around half a day to design.
  • Details Views: Usually require a full day of design work for simple details views.
  • Modals: Tend to take about 30 minutes to several hours to design, depending on complexity.

A junior UX designer, on the other hand, could take up to twice as long to complete the same tasks. Who is responsible for completing work is something I consider when delivering time estimates to clients. 

Estimating accurately is a skill that becomes more precise with experience and data collection over time. As your team gathers insights from completed sprints, you’ll be able to refine these estimates further. In the meantime, your design and development teams will be able to make initial time estimates by referring to past projects. The better your time estimates, the more consistently you’ll be able to deliver each sprint’s work on schedule and within scope.

Step 3: Plan Design Sprints

With your issues estimated, it’s time to organize them into sprints and establish the rhythm that will keep your design team ahead of development. Rather than trying to cram as much work in as possible, you should focus on creating a balanced, predictable pace that is always delivering valuable progress for the dev team. 

3.1. Set a Clear Sprint Duration and Goal

Most design teams work in two-week sprints, but the exact length isn’t as important as picking a cadence you can actually maintain. At Brandcave, a two-week sprint is equivalent to either 40 or 80 hours of work, depending on whether resources are allocated part-time or full-time to the project. Whatever you include in the sprint, the total estimated hours should get as close as possible to the sprint’s maximum capacity. Don’t forget to account for time spent in meetings, incorporating feedback, and handling inevitable curveballs.

Finally, each sprint should have a clear, achievable goal tied directly to your prioritized initiatives. By the end of the sprint, the team should be able to point to tangible progress toward that goal—so everyone knows what success looks like before the sprint even begins.

3.2. Fill Each Sprint Thoughtfully

Obviously, the highest priority initiatives should go first, but beyond priority order, you should also consider:

  • Dependencies: If one task relies on another’s completion (e.g., backend functionality required before frontend implementation), schedule the dependent task in a later sprint to avoid delays.
  • Time: Use time estimates to prevent overloading the sprint. Add up the estimated time for each issue to ensure it fits within the sprint’s time constraints, allowing some buffer for unforeseen delays or revisions.
  • Complexity: Mix high-complexity issues with lower-complexity ones to prevent a sprint from becoming too overwhelming. Maintaining a healthy balance will keep stress levels low and ensure multiple complex issues don’t spill over into future sprints. 
  • Capacity: Take into account each team member’s availability and bandwidth for the sprint. You want to make sure the workload is distributed evenly and no team member is stretched too thin. 
  • Cross-Team Coordination: While design and development teams will be working on different sprint schedules (more on that below), it’s still important to ensure that sprints are organized in a way that allows for easy handoff between teams. With the exception of strictly backend tasks, the design team should get their hands on a feature before the development team. 

3.3. Stay One Sprint Ahead of Development

Synchronized delivery only works when design stays at least one sprint ahead of development. Think of it like a relay race: design completes the first leg, handing off vetted, high-fidelity prototypes to the dev team, who then builds from a stable foundation.

To keep this rhythm:

  • Run separate sprint schedules for design and development. Both teams share the same prioritization, but the timelines must remain distinct.
  • Hold separate ceremonies—planning, standups, reviews, and retrospectives—so each team can stay focused. Invite a representative from the other team to design reviews or demos, but avoid merging schedules.
  • Keep design output consistent and visible so development is never left waiting or guessing what’s coming next.

Step 4: Parallel Delivery

During this final implementation step, you finally get to dig in and bring your ERB, IAB, and user flowchart into the real world. During this step, both design and development teams should be delivering work in a consistent cadence. When this approach is executed effectively, you should be able to maximize productivity for both designers and developers, avoid sidelining anyone, and maintain momentum throughout implementation. 

What should a typical sprint look like? Everyone manages implementation a bit differently, but for Synchronized Delivery to work, the design team needs to do these things: 

4.1. Groom Tickets for Clarity

Before each sprint, the design team should review and refine their backlog to ensure every issue is clear, scoped, and aligned with the sprint goal. Ticket grooming isn’t just a formality, it’s how you prevent mid-sprint chaos, reduce ambiguity, and keep design delivery on track for seamless handoff to development. When done well, it ensures each sprint will begin with clarity and end with confidence.

During ticket grooming sessions, the design team’s focus should be squarely on user experience requirements, interaction logic, and alignment with business goals. If your discovery documentation is solid and you’ve had little drift from the original blueprint, you might opt to skip grooming in favor of a short opening ceremony. But if there are still open questions or edge cases to explore, grooming is well worth the time.

If you do hold a grooming session, invite relevant stakeholders—especially a development lead from the other team. Their input helps prevent surprises and keeps implementation smooth. During the session, your aim is to align the tickets with the overarching goal of the sprint. This will help you make sure that all issues directly contribute to delivering meaningful outcomes for your project. If the sprint’s goal is to deliver core functionality for user onboarding, for instance, any tickets that don’t help you achieve this goal should be deprioritized. 

During design grooming, make sure you cover:

  • Clarify Ticket Requirements: Each ticket should clearly define what needs to be designed, why it matters, and what the intended outcome is. If something feels vague, fill in the gaps or ask clarifying questions before the sprint starts.
  • Break Down Large Issues: Split larger deliverables into manageable pieces (e.g., separating desktop and mobile flows). Each issue should be completable within a sprint.
  • Identify Dependencies: Call out anything that depends on prior UX work, stakeholder approval, or development infrastructure. Surfacing these early helps avoid bottlenecks later.
  • Define Acceptance Criteria: Establish what “done” looks like for each ticket. This helps designers know when to stop polishing—and gives developers a checklist for what they’ll need next sprint.
  • Prioritize Issues: Make sure the most critical work is scheduled first. If something isn’t essential to this sprint’s goal, consider pushing it to a future sprint.
  • Address Edge Cases: Talk through any weird user paths, interaction exceptions, or “what ifs” that could complicate a design. It’s better to handle these now than mid-sprint.
  • Check Sprint Fit: Use your time estimates to make sure the workload fits within the sprint capacity. If a ticket looks too big or uncertain, move it out and refine it later.

Remember, grooming for design is about shaping a sprint that delivers thoughtful, usable design work, ready to be built out with minimal confusion. Treat it as your chance to front-load clarity, so the rest of the sprint runs like clockwork.

4.2. Kick Off Each Sprint with an Opening Ceremony

Sprint kickoffs set the tone for the next two weeks of creative problem-solving. This ceremony aligns the UX team on sprint goals, clears up any lingering questions, and sets expectations for what’s being delivered and who’s doing what. Keep the tone focused but collaborative. The goal is to start the sprint with alignment and purpose. 

During your design team’s opening ceremony, make sure to cover:

  • What are we delivering? Confirm which features, flows, or components are being designed this sprint. Tie each one back to the broader initiative to reinforce the “why.”
  • What are our team goals? Go beyond the deliverables—set goals around quality, process, or collaboration. For example, “Reduce mid-sprint revisions by getting stakeholder feedback earlier.”
  • What could get in our way? Discuss known blockers like missing requirements, unclear logic, or unresolved technical constraints. Encourage team members to flag any personal capacity issues or uncertainties.
  • Who owns what? Review individual responsibilities so every designer knows their focus areas. Clarify who’s handling research, wireframes, prototypes, reviews, and documentation.

While design and development teams should hold separate ceremonies, a quick sync between team leads is a good idea for keeping timelines aligned. Since the design team should be one sprint ahead of development, this short check-in helps ensure the upcoming handoff goes smoothly. During the sync, leads can confirm that the design sprint will be delivering everything the development team will need next sprint, and it’s also a chance to call out any shifts in scope or priority. 

4.3. Conduct 60% Reviews to Stay Aligned

For the design team, a 60% review is one of the most effective ways to catch potential issues early and reduce rework at the end of the sprint. This informal check-in typically happens when a designer is a little more than halfway through their sprint work—early enough to course-correct, but far enough along to gather meaningful feedback. At Brandcave, this has become a standard part of our design process, helping us align stakeholders, make targeted adjustments, and refine work.

At this point in a sprint, a 60% review is an opportunity to:

  • Validate Progress: Ensure the design aligns with stakeholder expectations and sprint objectives.
  • Refine Functionality: Address detailed elements like usability, interactivity, and alignment with business logic.
  • Resolve Misalignments: Identify and address any remaining gaps or misunderstandings before moving into finalization.

This practice is especially beneficial when working with junior designers. Early feedback not only boosts their confidence but also provides valuable learning opportunities, helping them grow more quickly. Since implementing this approach on Brandcave projects, we’ve seen higher levels of team alignment, more effective end-of-sprint ceremonies, more engaged development teams, and ultimately, more thoughtful products. 

A 60% review may not always be the best fit for your team. You may choose to instead schedule check-ins at the midpoint of a sprint or even decide to combine this midpoint check-in with the ticket grooming session for the next sprint. The point here is simply that you are touching base to ensure progress is being made before the eleventh hour. Holding 60% reviews or mid sprint check-ins shouldn’t replace iterative collaboration throughout a sprint, though. If team members have questions relating to edge cases or unclear business logic, these questions should be addressed as early as possible to maintain momentum. 

4.4. Hold End-of-Sprint Ceremonies

Each design sprint should conclude with a structured handoff between the design and development teams to review, discuss, and align on completed work. In addition to demoing completed work, these syncs offer developers an opportunity to ask questions, clarify design elements, and understand key functionality directly from the design team, reducing the risk of misinterpretation once they start writing code. 

A successful end-of-sprint ceremony should include the following components:

  • Design Demo: The design team walks through the prototype, demonstrating page components, interactions, and screen transitions. This overview ensures developers see how everything fits together and how the user journey unfolds from screen to screen.
  • Stakeholder Q&A: Open the floor to feedback and questions from business leaders, developers, and any other stakeholders. This time allows them to ask for clarification on any unclear elements, address technical concerns, and provide input that may shape the final design. 
  • Documentation Review: Review any supporting documentation and assets, confirming that all resources the development team needs are available and accessible. This ensures that once the sprint closes and the designs have been handed off, developers have a clear roadmap to begin implementation without delays or questions.

When done right, end-of-sprint ceremonies should help keep projects on track and teams moving forward. For design, this means handing off clear, well-structured UX mockups that give development everything they need to start building with confidence. 

4.5. Adjust and Plan Ahead Based on Feedback

No sprint will go perfectly every time, especially as your team settles into their roles and gains a deeper understanding of the product’s goals. It’s expected—and valuable—to encounter a few bumps along the way. At the end of each sprint, take time to reflect on the previous two weeks. This review should include everything—the good, the bad, and the unexpected—because it’s only with honest reflection that you can iterate on your current process and improve future outcomes.

In particular, here are a few areas to look at when evaluating sprint performance:

  • Achievement of Sprint Goals: Review what was completed, what wasn’t, and how close the team came to meeting the sprint’s overall goal. If there were discrepancies, dig into the root causes. Was the sprint too ambitious, or were time estimates overly optimistic? On the flip side, if work was completed too quickly, it may indicate under-scoping, which could lead to inefficiencies.
  • Challenges Faced: Identify any blockers or issues that arose during the sprint. These challenges are valuable learning opportunities. Discuss ways to mitigate or prevent similar issues in the future, whether they’re related to resource availability, dependencies, or workflow bottlenecks.
  • Process Improvements: Reflect on what worked well and where the team can improve. This could involve refining sprint planning practices, adjusting communication strategies, or tweaking the process to enhance clarity. Small adjustments can make a big difference over time. 
  • Timeline & Budget Adherence: Ultimately, your ability to deliver on time and within budget is a primary indicator of success. Review whether the sprint stayed within these parameters and, if not, identify adjustments that will help meet these metrics more consistently in future sprints.

Using these insights, you can plan adjustments to keep future sprints on track. If you aren’t sure where to start, here are a few areas to consider:

  • Resource Allocation: Are team members spread too thin or underutilized? Adjusting resources can help balance workloads and keep everyone engaged.
  • Priorities: Ensure the highest-priority items are front and center for each sprint, aligning with your business goals and overall product roadmap.
  • Goals: Regularly evaluate and refine sprint goals to ensure they remain realistic and aligned with the project’s broader objectives.

Synchronized delivery—and Blueprint Agile as a whole—doesn’t have to be perfect on your first attempt. Like any skill, it gets better with repetition. Over time, you’ll learn how to set more focused sprint goals, tighten up your review cycles, and give design QA and documentation the space they need. As long as your team stays one step ahead of development, your mission stays the same: deliver high-quality designs on time, without sacrificing clarity or creativity.

Synchronized delivery is ultimately a team sport. When designers stay aligned on priorities, communicate proactively, and improve their own process with each sprint, they give the development team exactly what they need to keep building without pause. In the next chapter, we’ll shift focus to the development side of synchronized delivery—how engineers use this same structure to plan, build, and ship with speed and precision.