How to Run a 30-Day Automation Discovery Sprint: A Practitioner's Playbook

The organic approach to pipeline building - waiting for business users to submit ideas over time, handling each intake as it arrives - can leave a pipeline undersized and dependent on whoever happens to be submitting. It's reactive, and reactive pipelines produce reactive programs.

The alternative is the discovery sprint - an intensive, structured period of active pipeline building where the CoE goes to the business rather than waiting for the business to come to the CoE. A time-boxed sprint can generate qualified pipeline, establish relationships with business stakeholders in new departments, and create a repeatable playbook for future cycles. Output depends on participation, scope, and review capacity, so measure it against your own baseline.

Week 1: Stakeholder Mapping and Sprint Setup

Day 1–2: Identify Target Departments and Executive Sponsors

Before the sprint begins, identify a manageable set of departments or business units where the sprint will focus. Selection criteria include process volume and complexity, available executive sponsorship, and departments that have not been active in the automation program previously.

Day 3–4: Brief Stakeholders on What to Expect

The sprint kickoff briefing is critical for setting expectations and motivating participation. Business users need to understand: what an automation opportunity looks like (and doesn't look like), why their input matters, how long the intake process takes, and what they'll receive in return (a qualification report, an ROI estimate, a clear recommended next step - not just a form acknowledgment that disappears into a queue).

Day 5: Configure and Test the Intake System

Ensure the intake platform is configured for the sprint: correct organizational mapping, relevant department options, appropriate technology catalog for each department's likely tool stack. Run a test intake with one of your own team members playing the business user role. Identify any questions or flows that are confusing and refine before opening to the business.

Week 2: Active Discovery

Day 6–10: Open Intake and Drive Submissions

The sprint's active phase can open with a direct, time-bounded ask to each department's stakeholder group: invite stakeholders to submit their most important process pain points during the agreed submission window. Set intake duration and report-delivery expectations from your own workflow capacity rather than promising universal timings.

Don't wait for submissions to come in. Follow up during the submission window, offer short kickoff calls to answer questions, and remove barriers to participation. Measure conversion against your own prior sprints rather than relying on a universal rate.

Week 3: Review and Qualification

For the sprint's interview stage, use IntakeOS to conduct participant conversations and structure their answers instead of asking analysts to run and collate every session. Spend the review week checking maps, estimates, and disputed exceptions with owners. A fixed sprint duration is a planning choice, not a guarantee that every candidate will reach implementation readiness within thirty days.

Day 11–15: Review AI-Generated Qualification Reports

If you're using AI-powered intake, qualification reports will be available immediately after each submission completes. Review them for completeness and accuracy - flagging any intakes where the data seems inconsistent or where important questions weren't resolved. For flagged intakes, use the Deep Dive feature to request targeted follow-up questions rather than scheduling new workshops.

Day 16–18: Pattern Verification and Preliminary Prioritization

Validate the AI-recommended patterns against the intake data. For complex or ambiguous candidates, involve a senior technical resource in the pattern review. Begin preliminary prioritization using a consistent scoring framework: ROI potential, implementation complexity, strategic alignment, and time to value. Surface the preliminary prioritization to a CoE steering group for alignment.

Week 4: Handoff and Sprint Wrap-Up

Day 19–22: Create Development-Ready Briefs for Top Candidates

For the top 10–15 candidates from the sprint, prepare development-ready briefs that include: the qualification report summary, recommended pattern and rationale, ROI estimate and methodology, preliminary effort estimate, recommended builder profile (specialist or citizen developer), suggested next steps, and stakeholder contacts for follow-up. These briefs allow developers to pick up candidates from the sprint pipeline without any additional discovery work.

Day 23–25: Sprint Retrospective and Stakeholder Feedback

Conduct a retrospective with the CoE team: what worked, what didn't, what would improve the next sprint. Separately, gather feedback from business stakeholders on their intake experience - was the process clear, was the timing manageable, did the qualification report provide value? This feedback improves subsequent sprint designs and builds stakeholder trust.

Day 26–30: Documentation and Next Sprint Planning

Document the sprint output: number of candidates submitted, number qualified, pattern distribution, total ROI potential, and departmental breakdown. Use this data to decide whether another sprint is warranted and to refine targeting for a future cycle. Set the cadence from local demand, review capacity, and observed pipeline health rather than assuming a universal schedule.

Sprint Metrics: What Good Looks Like

• Target submission rate: set a local participation target for briefed stakeholders and compare it with prior sprints
• Qualification rate: measure how many submitted processes pass the root cause gate as genuine automation candidates
• Pattern distribution: report the observed mix of RPA, API/Integration, BPM, IDP, and GenAI/ML for this sprint; there is no universal mix
• Pipeline value: quantify qualified automation opportunity from validated local assumptions rather than a generic dollar range
• Time to first development start: track when top-priority candidates enter the development queue after sprint close