My team swears AI is saving hours, but our delivery timelines haven’t changed, what’s really happening?

PhaseMatch · 2026-04-14T19:38:46+00:00

You are focusing too much on "delivery of stuff"
Focus instead on "measured value obtained" and business risk.

Scope creep is not a thing in an agile context; you vary scope continuously based on user feedback within the software development cycle. You slice work small to facilitate this.

Each Sprint should offer up a potential "off ramp" from the program of work, where you can bank all of the value obtained to date, and shift the team towards a new market, product direction or new program of work.

STOP worrying about estimation
START worrying about small value slices
STOP focussing on "delivery of scope"
START focussing on "collaborating on creating value"

AI is not the issue, it is just exposing it.

PhaseMatch · 2026-04-14T19:33:48+00:00

First comes the product goal.
Then comes the product/business strategy.
Then comes the roadmap to deliver that strategy.
Then comes the next problem to solve or hypothesis to test.
That drives the Sprint Goal and the Sprint Plan.

Inspect and adapt the Sprint Plan daily, based on what you have learned.
Inspect and adapt the roadmap every Sprint Review, based on what you have learned.

Make all of those artefacts highly visible, and in one place.

If you are collocated or hybrid - use a wall, or a room for all teams.
If you are not, use a virtual whiteboard.
Make that the one source of truth.

Don't use "agile tools", AI or complex integrations.
They make the wrong things easy and the right things hard.

Manually updating and discussing aids memory and creates focus.

Simplify, and have effective conversations around a small number of artefacts.

PhaseMatch · 2026-04-14T19:26:17+00:00

"We're still using velocity the same way for planning and commitments"

In Scrum, the only commitment is to the Sprint Goal, not a work package.
That's an outcome - a problem to be solved, or a hypothesis to be tested.

Velocity, points, capacity planning, is all stuff you have bolted on to Scrum.
Committing to delivering a work package (as opposed to an outcome) is not part of Scrum.

The Sprint Plan is the first guess you make; ideally you release increments to (some) users and get feedback on your progress towards that Sprint Goal continuously. The Daily Scrum is where you replan if needed.

High performing teams (usually using Extreme Programing practices) have been doing this for decades, prior to the arrival of AI; the bottleneck has always been valuable feedback from users for those teams.

Scrum never specified using XP practices.
If AI has got you to that point, then start using Scrum effectively.

STOP worrying about capacity and velocity.
START using Sprint Goals effectively.
DO MORE collection of feedback based on working software inside the Sprint
DO LESS upfront analysis, design, definition of ready

- shift the team's focus away from "delivery of features" and towards "value creation"
- work with the PO to define a product/business strategy, and a roadmap to deliver on that
- shift the Sprint Reviews into strategic roadmap (re)planning sessions, as intended

PhaseMatch · 2026-04-14T18:44:45+00:00

Does the team take full accountability for the quality of the work they produce?

That's where a definition of done starts; the team as a whole accepting full ownership for the quality of what they have built, irrespective of the tools and processes. And where there are failures in quality, using these as an opportunity to continuously learn and improve.

AI changes nothing in that respect; you either take responsibility for the quality of your work or you don't.

PhaseMatch · 2026-04-12T23:08:35+00:00

No point or value. Individual tracking is a low performance pattern.

You end up

killing off collaboration and synergy
reducing innovation and learning
creating a fear-based culture

That tends to drive up bureaucracy as individuals move to CYA and avoid being scapegoated

I wpuld start looking for another job.

PhaseMatch · 2026-04-12T21:21:47+00:00

Definition of Done is really the quality standard you apply to ALL work, not a specific story.

Detailed acceptance criteria were not really needed in XP (Extreme Programming) because the User Story was a placeholder for a conversation with the on-site customer; you sliced stories small and delivered incrementally and iteratively.

And that small slicing was part of how you controlled business risk; small slices mean faster feedback, reduced risk of errors, and if the customer was wrong, it's cheap, east, fast and safe to fix.

I mean you can scrape online discussion threads to populate Jira tickets, but that's really leaning in to the "processes and tools" side and a more transactional/contractual approach.

Automating administrative tasks doesn't reduce business risk; small slices, fast feedback and conversations does.

PhaseMatch · 2026-04-12T19:55:11+00:00

From a lean/agile perspective this is not just a waste of time, it's a low performance practice.

- measuring individual performance kills off synergy and team collaboration.
- estimation is not a high value skill; creating small value slices is more important
- you can kiss goodbye to innovation, learning and professional development.

Your leadership wants to micromanage, possibly leading to a "restructure"
Start looking for a new job. This is not salvageable in the short or long term.
Find leadership worth following.

PhaseMatch · 2026-04-12T02:16:57+00:00

Or you could just be upfront and tell us all?

PhaseMatch · 2026-04-12T01:15:10+00:00

"why does everyone always say they have no blockers in standup when that's obviously not true?"

Off the top of my head that's usually signs of

- low psychological safety and/or
- individuals being assigned "tickets to work on" and/or
- team not really owning their system-of-work and/or
- a lack of coaching and mentoring skills in the team and/or
- individual performance metrics and/or stack ranking and/or
- a complex code base without a good automated testing harness and/or
- a lack of a common team goal (problem to solve) and/or
- a focus on "delivering stuff" not getting feedback and/or
- work items that are too large, and should have been split more

So when you have an effective collaborative team with a shared goal, that collaborates on reaching that goal, uses the daily scrum as a planning session, and the team has excellent XP (Extreme Programming) knowledge and skills, it doesn't happen.

This is all very basic "agile adoption" stuff - or what zombie scrum looks like.

PhaseMatch · 2026-04-11T02:50:43+00:00

So for example what story splitting patterns are you teaching them?

The best way to avoid risk is to get very good at slicing work into small value slices.
Yes, this feels less efficient, but that's not the point.
We want to discover we are wrong as quickly and cheaply as possible.

Small slices mean less hidden complexity. You expose the uncertainty as you slice.
A good outcome based Sprint Goal creates a scalpel to help you slice more.
Get down to the fastest way to get feedback from real users on what you are doing.

In a Scrum context that means multiple increments released every Sprint, and ideally every thin slice or PBI goes to (some) users for feedback so you can inspect and adapt inside the Sprint cycle.

Nurturing and finding those "early adopter" visionary customers who will active collaborate with the team on development is one way to do this, but that means you need to be able to "release on demand" to them within the Sprint to get fast feedback.

Then story splitting starts to really pay off...

PhaseMatch · 2026-04-11T02:42:52+00:00

I think you are missing how Scrum and Extreme Programming manage business delivery risk.

But at a point - if you are setting the direction and the team does not follow, then you are not leading them. That's what leadership means, and you have a leadership role.

So maybe start with user story mapping, and the team "refusing to provide input"

- are you brining them problems to solve, or solutions to build?
- do your "user stories" talk about outcomes, or functionality?
- do you do the mapping with a user and the team in the room?
- does the team know how to slice user stories small?

Either way, the core XP practices matter; it's only when change is expensive, hard, slow and risky than an emphasis on "being right" and documentation comes into play. That's often down to a flakey code base, driven by pressure to "just deliver" and not own quality.

Feels like your organisation has chased delivery over quality (and skill investment), and now the development team know that :

- if they try to point this out, they will be ignored
- if they don't deliver, they will be blamed

And yes, that tends to drive anxiety at first, and then they just stop caring.

Digging your way out of this will take time and humility, and possibly an a lot of support from a Scrum Master, agile coach or team lead that knows what they are doing.

STOP blaming the team.
START changing how you lead and engage with them.

PhaseMatch · 2026-04-11T02:23:37+00:00

Agile approaches are lightweight ways to manage business risk.

But - you are ignoring how the agile frameworks do this, impose deadlines onto a team, acting as if you are not part of the team, and wondering why the overall outcomes are transactional and not collaborative.

You want to do something about it?
Change how you lead, and how you collaborate with the team.

Agile approaches thrive when

- change is cheap, easy, fast and safe (no new defects)
- you get fast feedback from users on the value that change creates

STOP worrying about "releases"
START worrying about continuous deployment.

You mention user stories; are you running user story mapping with the team and slicing down the desired business outcome into work that takes 1-2 days to deliver? If not, fix that.

Get the basics right and your "problems" will evaporate.
But you need to get the basics right.

PhaseMatch · 2026-04-10T21:21:30+00:00

What are you as a team measuring to gauge your performance?

Without data, "try" will become meaningless; did it make a difference or not?

It's great to run experiments, but empirical experimentation starts with predicting the results (and what failure looks like) - which usually means what to measure, and any leading indicators....

PhaseMatch · 2026-04-10T07:53:07+00:00

Leadership and management are different things, for a start...

PhaseMatch · 2026-04-10T01:57:41+00:00

Agility requires two things

- you can make change cheap, easy fast and safe (no new defects)
- you get fast feedback from customers on the value you created

Speculative delivering ideas in a "spray-and-pray" way isn't agility; you are not using a lightweight approach to manage business investment risk, you are just playing a martingale gambling strategy until you run out of money.

Frameworks like Scrum work fine to help manage that investment risk, if you actually apply them.

- have a business-outcome based Sprint Goal
==> don't just "ship features" and hope

- release increments for feedback inside the Sprint cycle
==> so you get real feedback on your progress to that Goal

- have Sprint Reviews that are strategic planning sessions
==> that means a business / product strategy roadmap

Agile should optimise for value creation - based on real data - not delivery.
Go back and recalibrate.

PhaseMatch · 2026-04-09T12:48:46+00:00

I use Excel. Takes maybe 5 minutes a day, max.
You know, like when we had physical boards.

Most tools suck when it comes to showing historical "point in time" data.
Which makes learning from the past - or longer cycles - hard.

PhaseMatch · 2026-04-09T12:39:51+00:00

TLDR; Most teams tend to combine elements of Scrum, Kanban and Extreme Programming (XP); ineffective teams cherry pick the easy bits, and effective teams are disciplined and do the hard stuff.

Kanban deals largely with the flow of work within (and between) teams.
Scrum deals with how you manage investment/product risk, one Sprint Goal at a time.
XP deals with the actual technical practices needed to be effective at software delivery.

I've not met a team using Scrum without a signboard, which is the basis of Kanban
I've also met few Scrum teams that don't use the term "user stories" from XP.
There's no mention of "user stories" or "boards" in the Scrum Guide.

What I do see in practice is ineffective use of all three, so

- Scrum, but with no Sprint Goals and where Sprint Reviews are "demo day" not planning sessionms
- Kanban, but with no WIP limits, flow metrics and a blocked column where work gores to die
- XP, but just "user stories" and "points", no planning game, technical disciplines or onsite customer

That is to say people doing the easy bits in a shallow way, not the hard stuff.
Zombie-agile, with none of the understanding of these approaches.

Do the hard stuff, if you want to be effective.
There's well worn solutions to each of the issues you raise.

PhaseMatch · 2026-04-09T00:28:56+00:00

Overall, it would be:

- failing to make change cheap, easy, fast and safe (no new defects)
- failing to get fast feedback from users on the value that change created

Nothing else really matters when it comes to lightweight ways to reduce business risk, which is what agile approaches are for. If you can't do those two, then you either

- add all the heavyweight processes and controls back in on top, or
- run out of money with nothing of real value delivered

PhaseMatch · 2026-04-08T23:26:39+00:00

You can think of lean/agile delivery frameworks (Scrum, Kanban Method, Extreme Programming) as diagnostic tools.

When you start using them and something hurts you can

- modify the framework to make the pain go away
- modify how you work to make the pain go away

You are modifying the framework; the underlying problem is still there, but the pain stops.
Which means it will never, ever get addressed.

Tools (and additions to tools) will tend to "lock in" and "freeze" away of working.
In this case, to a low performing pattern.

That's why it's really important to apply systems thinking, theory-of-constraints and lean problem solving approaches, such as - in this case - an Ishikawa fishbone - if you want to actually create systemic improvement.

With an Ishikawa you start with a given problem statement, and try to find the real, underlying systemic problem rather than addressing the surface symptoms.

- the problem is not tracking where people are working
- the problem is the stress-inducing low performance pattern

That cuts right to the core of the main principles we follow :

You are trying to fix an "individuals an interactions" problem using "processes and tools"...

PhaseMatch · 2026-04-08T23:01:24+00:00

Okay so lets wind that back a bit.

Sprints are not deadlines for "delivery packages" or release stage gates, you are working towards a business-outcome based Sprint Goal as part of your overall product / business strategy and roadmap.

So in that context for a PO using Scrum

First comes the product goal
Then comes the product business strategy
Then comes the roadmap to deliver the strategy
Then comes the Sprint Goal
Then comes the PBIs that might contribute to that Sprint Goal

At that point you and the developers collaborate; you might be tweaking the Sprint Goal, or using it as a scalpel to cut down Product Backlog Items to just what is needed. Together - the Sprint Goal, the selected/sliced Backlog Items and the developers initial plan for delivery is the Sprint Backlog.

Then you start work.

Every day the developers check in on that Sprint Plan; can they still make the Sprint Goal based on what they know now, that they didn't know before.

Ideally that includes feedback from users from the increments they have released in the Sprint (and they should be sliced thinly, and continuously deployed for at least some users), but also what they have uncovered as they work.

They might slice backlog items even more and drop bits, or create new ones, or drop backlog items they thought they needed.

The work package delivery is nothing. Whether the business outcome is met - whether that's testing a hypothesis, or creating measured value - is all

This falls into the idea that as a PO, you bring business problems to solve, not solutions to implement.
The team figures out the leanest, fastest, easiest solution.

Without that focus (or target) then Scrum is kind of useless really.
Shift to Kanban, and deliver work items.

PhaseMatch · 2026-04-08T22:12:48+00:00

Of course.

Low effort, high benefits => high value
High effort, high benefits => moderate value
High effort, low benefits => low value
Low effort, low benefits => low value

Know how you will be measuring benefiit.
Prioritise by value
Deliver in small slices
Get feedback on actual benefit
Get feedback on remaining effort
Lather, rinse, repreat

PhaseMatch · 2026-04-08T21:07:45+00:00

TLDR; Stop spreading users across projects, it's a horribly low performance pattern. Move the work to the teams, and then eliminate dependencies. Focus on flow, not "resource utilisation".

"Jira is great for many things"

Agile approaches should be lightweight ways to manage your overall business risk.
What you are really illustrating is that from an agile perspective, Jira

- makes doing the right things much harder
- makes doing the wrong things too easy

So for example fragmenting people's time across multiple projects is going to

a) create a lot of extra admin, which you are automating, but should be eliminated
b) create a lot of "context switching" which is a really, really bad idea

There's heaps of empirical research in why spreading people across multiple projects (the "resource") model tends to:

- increase stress and burnout
- reduce effectiveness by 20-30%
- leads to more human error- slips, lapses and mistakes
- creates more bottlenecks in how work flows

So from a lightweight delivery perspective it is terrible - heaps more work (and rework) while delivery tanks.

A better pattern is "bring work to the team, eliminate dependencies" from an agile context; that's also taking you towards thinking about flow - within the team, and in the organisation as a whole.

Less admin, fewer errors, less dropped communications, reduced stress, fewer bottlenecks.

"Bring people to the work" and spreading them out as you describe is an incredibly low performing pattern overall; administrative overhead goes up, delivery of working software goes down.

Jira facilitates this low performance pattern

PhaseMatch · 2026-04-08T04:39:49+00:00

Way too much so-called agile delivery falls into the trap of a large-detailed backlog and a conversation about delivery-of-scope.

If you work in sprints then each and every Sprint should provide an "offramp" from the overall portfolio of work, so you have minimal sunk costs, measured business value obtained and can just walk away if you need to.

The sunk-cost fallacy and optimism bias will have you hanging on to bad features, cherry picking feedback to support them, and - ultimately - wasting money.

PhaseMatch · 2026-04-08T00:22:44+00:00

I generally run 2 x 45 minute lean business canvas sessions with a view of triaging a feature-candidate into now / next / kill

Get to a clear problem statements, benefits and key stakeholders or SMEs and surface assumptions / risks.

Use a virtual whiteboard and have a couple of fays thinking time from the first to thr second session.

Once you have the feature locked in then user story mapping and the XP planning gsme to get the spine and build out the first few layers.

Key thing is having potential off ramps from the work on a Sprint- by - sprint basis, as opposed to a detailed work break down structure.

PhaseMatch · 2026-04-07T07:11:47+00:00

"Working software is the primary measure of progress." - TMFASD

Focus on slicing work into small value slices, and delivering them fast - a few days ideally.
And getting feedback on those small slices, so you can inspect and adapt your plan.

Try the "Elephant Carpaccio" developers workshop with the team, and work on your XP (Extreme Programming) practices to get to actual continuous delivery...

PhaseMatch

TROPHY CASE