Involving Developers Early in the Development Cycle

At Parser , our experience delivering solutions for clients in the retail industry has shown that involving developers early in the development cycle leads to measurable improvements in product quality, development predictability , and team velocity.

23 Oct 2025

Ho wan Fong

Product and engineering

Culture and team

By Ho wan Fong, at Parser

Introduction

At Parser, our experience delivering solutions for clients in the retail industry has shown that involving developers early in the development cycle leads to measurable improvements in product quality, development predictability, and team velocity.

For example, during a recent project with a major retail client, early developer involvement helped us identify integration risks before sprint planning, reducing rework by 30%.

One of the highest‐leverage moves a Product Manager (PM) or Product Owner (PO) can make is to involve developers from the first step of ideation through to ticket creation, rather than after scope and design are already set.

This article aims to provide you with an understanding of this approach, the rationale behind it, and practical guidance for implementation.

Change of Ways of Working

Diagram 01 — Illustrates the main changes in the backlog generation process

Benefit expected

By adapting with the ‘involving developers early’ approach, we can expect:

Significantly increase the understanding of business content and feature requirements for the whole development team
Reduce development work delay due to uncertainty
Increase sprint predictability

As a result, several development team health metrics are positively impacted, including but not limited to:

Team’s average cycle time
Feature estimation accuracy
Less spec-related rework after planned development work
More user-centric suggestions from developers
Rate of knowledge diffusion for Junior developers in team

Why We Changed

Our cross‐functional experiment surfaced the following goals:

Improve predictability of delivery and overall team velocity (dramatically increasing from around 50 story points per sprint to around 60–70 story points per sprint) in the long term
Share responsibility for product quality with developers
Identify risks, blockers and dependencies as early as possible
Break down knowledge barriers; raise the minimum experience level of the whole team
Involve everyone, regardless of seniority, in shaping the solution
Grow developers into experts in product and user needs
Foster stronger collaboration and engagement

The sections that follow describe exactly how we achieved those outcomes.

Alternative Approaches Considered

Before settling on our collaborative workflow, we evaluated other industry practices:

Shape Up (Basecamp): Focuses on upfront shaping of work by senior staff, with developers involved after the “pitch” phase. We found this less effective for rapid feedback in our distributed teams.
Dual-Track Agile: Runs discovery and delivery in parallel, with developers involved in both. While promising, it required more resources than our typical client teams could support. We chose our current approach because it balances shared ownership, rapid feedback, and fits our client engagement model.

From “Throw‐It‐Over‐The‐Wall” to Collaborative Design

The diagram below visualises the shift from a traditional, sequential flow to our new collaborative loop.

Diagram 02 — Collaborative flow method.

Key Shifts

Core Concepts

1. Feature Specifications

Old: PO/ TL wrote 100% of specs and tickets
New: PO/ TL prepare a 70%‐ready Epic’s spec, then run workshops with the team to reach 100%
Result: Developers understand the why and what, can question assumptions, and share accountability

2. Architectural Design

TL prepares a 50% draft architecture
The whole team iterates until the approach is fully understood and agreed
Developers level‐up on system design and challenge trade‐offs early

3. Backlog Refinement

Developers (sometimes in pairs) create the tickets themselves, embedding links, references and acceptance criteria.
Tickets transition from “Backlog” to “Refining” once drafted, signalling readiness for peer review and estimation

Step‐by‐Step Workflow (Ticket Creation)

Below is the distilled process we now follow for each new Epic or Feature (if large enough), which can be used as a checklist.

Tip: For large features, repeat Steps 5‐7 per Epic to keep workshops short and focused.

Real Example in Practice

Working in one of the leading data science companies that provide customer insights in the retail and consumer goods industry, during a new feature development process, we piloted a collaborative workflow for involving developers in the early stage of development. Product owner, Technical lead and developers in this team actively participate in joint ticket creation sessions, leveraging our internal documentation templates and Jira automation scripts. This approach was the first time being tried for adoption among all teams within this client, with the assistance of a senior manager (who is also from Parser). Although developers initially resisted the ticket creation process during the first iterations, as the focus was on the conversation and understanding, the practice was later adopted, and the whole team perceived the benefits of it.

Our team is the first and one of the most successful teams (significantly reducing development cycle time) to adopt this new approach, actively share our experience, and provide feedback for other teams adopting this approach across the client structure.

Pro Tip: We found that pairing a senior and junior developer for ticket writing not only accelerated onboarding but also led to more robust acceptance criteria.

Benefits Observed

Our teams observed that this collaborative approach fostered a stronger shared understanding of requirements. In our project, for instance, cross–functional workshops reduced handoff delays and improved sprint predictability, as measured by our internal velocity tracking dashboards.

The team’s average cycle time improved from 14 to <10 days after adoption, as tracked in Plandek
20% more accurate in feature estimates (teams report fewer surprises during sprints)
40% reduction in spec‐related rework post‐development
30% increase in user-centric feature suggestions from developers, as tracked in our internal suggestion board, following the adoption of early involvement workshops.
Improved knowledge diffusion: junior engineers contribute earlier and progress faster
Shared ownership increases morale and cross‐functional trust

Lesson Learned

Our internal retrospectives highlight that early developer involvement surfaces technical risks and dependencies sooner. For instance, during a discussion about creating one of the Deep Dive tables by using client’s existing modules, developers flagged a critical component limitation during the initial ticket workshop, allowing the team to adjust the scope before sprint commitment.

Tips for Running Efficient Workshops

We piloted a ‘rotating facilitator’ model, where a different developer (including juniors) led each ticket creation workshop. This not only accelerated onboarding but also surfaced process improvements, such as our “parking lot” for any out-of-scope ideas
Use timeboxed brainstorming (e.g., Crazy‐8s/10s ideas) to surface diverse perspectives quickly
Pair a senior + junior developer for ticket writing to accelerate onboarding
Keep a parking lot for deep dives that could derail momentum; schedule follow‐ups
Capture decisions instantly in Confluence to avoid forgotten context