About a month ago, fresh off the momentum of our Github Copilot hands-on workshop, my brilliant engineers took on the challenge of running an AI-assisted sprint. For me, as an engineering manager, it was a great opportunity to observe how AI might actually support and enhance our ways of working. I was well aware of the sceptics and the not-so-positive noise around AI “taking over humanity”, but I didn’t want that to be the reason we avoided trying something new. At the end of the day, this was an experiment.
To really put the AI to the test (Github Copilot, to be specific), we picked a chunky feature that required a fair bit of effort across both the backend and frontend. My team includes three backend engineers, two frontend, one QA, a designer, a tech-savvy product manager, and me. (I’ll come back to how important the product manager’s personality turned out to be.) For the experiment, we formed a focused squad: one backend and two frontend engineers.
Before kicking things off, we had a short planning session and came up with three simple ground rules:
- Use Copilot as much as possible.
- Log your experience daily on a Confluence page (prompts, pain points, tickets, observations, everything).
- Deliver as you normally would, but let AI help wherever it can.
We kicked off the new sprint. Nothing felt different really. Stand-ups were business as usual, and all the standard rituals stayed in place; refinement, 3 Amigos, other syncs, we didn’t cancel a thing.
Fast forward 10 days, and it was time for our sprint review. For those that don’t know, this is the session that happens just before the retrospective, where we look back at our goals, the board, and what we’ve delivered. If there’s something to celebrate, we sing and dance. If there’s something to learn, we call it out, own it, and jot it down.
How are we measuring productivity?
Before jumping into the results, I think it’s worth explaining how we compared delivery rates with and without AI to get a more realistic picture. We use story points on our tickets to reflect complexity. The feature we picked for this experiment had been fully refined and pointed by the engineers beforehand.
We also asked ourselves: for similar work, based on past sprints and with the same capacity (taking into account working days and sprint rituals), what would the typical velocity be for each engineer to complete the tickets?
The backend engineer estimated around 10 story points per sprint for similar tasks. We posed the same question to the frontend engineers and captured their answers as well.
Speed meets complexity
The backend engineer delivered 25 story points (a 150% increase compared to their usual velocity).
The frontend engineers also reported a 30% uplift in their development pace.
The reason we didn’t see the same level of progress on the frontend, despite having two people, was down to the complexity of the UI work. The components were much trickier for Copilot to get right. Engineers often had to switch between models, pause, clean up, and sometimes start again from scratch. And of course, the learning curve played a part too.
Syncing frontend and backend work
Ideally, an agile team works together on a feature from start to finish, then moves on to the next and delivers value continuously. But when there’s an imbalance in frontend and backend velocity or bandwidth, the two disciplines can fall out of sync. It’s a challenge that needs addressing. You don’t want your backend engineers jumping onto new work while others are still playing catch-up.
Time to rethink QA for speed of delivery
Another area that stood out was the QA process.
As our implementation pace picked up, it naturally led to more and more tickets piling up, waiting to be tested. It became clear that we need to scale our QA efforts and shift more towards automation.
How the team embraced Copilot
Some engineers were initially hesitant to use Copilot and that’s completely understandable. What’s interesting is that even the more sceptical ones are now using it confidently and without hesitation. There’s definitely a learning curve, but over time they will improve at crafting more tailored prompts and getting results that meet their standards.
Remember I mentioned the importance of your product manager at the start? Let me explain why that matters so much.
As engineering managers, we focus on creating a healthy, productive environment, removing blockers, ensuring technical quality, and helping the team grow.
But to truly deliver impact, we need a partner who understands the ‘why’ behind the work as much as we understand the ‘how’. That’s where a strong, curious, and tech-savvy product manager comes in.
When you have that kind of PM next to you, the team operates with clarity and momentum. They help shape the vision, prioritise the right problems, and keep everyone anchored to the customer or consumer. They’re not just there to manage a backlog; they’re collaborators, sounding boards, and co-pilots (pun intended).
In this experiment, I was lucky to work with exactly that kind of product partner. She was hands-on, keen to learn, and quick to adapt as the team gained more capacity with AI tools. We shared the wins and discussed the challenges together. That balance between product thinking and engineering execution made all the difference.
And what about Copilot itself?
AI is now like a new team member in the team, and it’s a welcome one. We agreed that there are certain types of tasks where AI can be incredibly helpful. Things like extending existing design patterns, adding new contracts, working on APIs and their documentation, or even doing version bumps. Engineers are happy to delegate these tasks to Copilot so they can focus on more complex and meaningful work.
To help track this shift, we’ve also decided to use a copilot label in Jira whenever a ticket is mostly written by AI (over 70 percent for us). Engineers are encouraged to leave a comment on the ticket noting roughly what percentage of the work was done by AI. This gives us better visibility and helps inform future decisions about where AI support brings the most value.
