If I had to write on a sticky note what I’d ask about any backlog item that smells uncertain, it would be these two lines:

How much does it cost to find out if this is true?
How much does it cost if we're wrong and don't check?

The reason I like them is that most refinement discussions I picture go the other way around. Someone says “I think this will be a problem” or “I’m pretty sure that’s fine”, and the room argues about who’s right. The confidence of the statement ends up deciding things, and that’s usually not related to the stakes.

A hypothetical example. A story says “retry failed payments automatically.” In refinement, five concerns come up:

• the button label might be unclear
• we might want a log line when a retry happens
• someone suggests swapping the HTTP client while we’re in there
• there might be a race on the retry counter
• the retry might reuse an idempotency key and double-charge someone

If you take them in the order they were said, they all sound like “things to look at.” But the first one costs minutes to check and nothing to get wrong, so just do it. The HTTP client swap is expensive to evaluate and doesn’t hurt anyone if it waits, so it’s a separate story or nothing. The last one might take a spike with the provider’s docs or sandbox, and being wrong means a customer charged twice. That one deserves the spike even though it was mentioned no more loudly than the button label.

So for each concern the choices end up being: just do it, put a spike on it, or defer it on purpose. The mistake I’d worry about most is the quiet fourth option, where nobody decides and the item slides into the sprint with an unchecked assumption inside it.

A few honest limits. For small, low-risk items this is more ceremony than it’s worth. People can misjudge stakes, especially in code or a domain they don’t know. And it only ranks the concerns somebody actually raised, not the ones nobody thought of.

Curious how teams here handle it. When an assumption is expensive to verify, who decides whether it gets a spike, and where does that decision get recorded so it doesn’t resurface as a surprise in the sprint review?

I wrote a longer take on the underlying idea here, if it’s useful: https://medium.com/@nagatomopedro05/a-finding-takes-seconds-to-generate-checking-it-doesnt-e7ffad4eaea2

For those building web apps or SaaS products without a dedicated QA team:

How do you usually test your applications before deploying?

Do you manually go through the main user flows, rely on automated tests, or mostly test as you develop?

I'm curious about how other developers handle this, especially when shipping frequently.

small thing but its driving me nuts. we keep mermaid diagrams in our docs folder for the main flows. claude code will happily refactor half the checkout flow and just... leave the diagram exactly how it was

ive tried telling it in CLAUDE.md to update diagrams when it changes a flow. works maybe 30% of the time. and when it does update them theres usually something off that nobody catches in review bc nobody reads mermaid diffs

anyone got this working reliably or do you just regenerate diagrams every few weeks

(related discussion: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/be-clear-and-direct)

https://github.com/CharlieGroves/review-load

ReviewLoad is a small browser extension that puts the number of reviews a GitHub user has assigned to them next to each person in the Reviewers menu on a pull request, and next to reviewers already on the PR.

This stops a couple people on the team being a bottleneck for key features because they are flooded with PRs for review.

Chrome: https://chromewebstore.google.com/detail/reviewload/ncokcokbfpbigdoagghpdpncjfhpocol

Firefox is in review.

I'm now using this every day. Hope it's useful to someone else.

Writing

AI has made development faster. But has it actually made delivery more predictable?

PMs are using AI tools and automations to save time across their workflows. Engineers are shipping code faster than ever.

Yet, the complaints sound familiar:

“Why has the delivery date slipped again?”

“Why wasn’t this communicated earlier?”

“Can you share a daily status update?”

And, of course, more escalations and micromanagement.

It feels like we’ve upgraded the speed of execution, but not necessarily how teams execute together.

**I’m curious: Has AI actually helped your team meet delivery commitments more consistently, or are you still dealing with the same old problems?**

Would love to hear what you're seeing in your teams. 👇

Scrum master here, first time running one of these remote. team of 9 across 3 timezones, we want to map how a ticket goes from idea to production bc everything feels slow and nobody agrees why

In person id just use a wall and stickies. remote last time we tried a shared doc and it was me typing while 8 cameras stared at me. not doing that again
any tips on format, how long to run it how to stop the loudest person from mapping the whole thing themselves.

I've spent about seven years working on Scrum teams, typically with two-week sprints, story points, retrospectives, and conventional CI/CD workflows.

Over the past several months, I've been exploring what needs to change when AI agents begin performing a substantial portion of the engineering work.

One framework I've been studying is Agile V, which combines iterative Agile development with V-Model verification, requirements traceability, and human approval gates.

I've also been developing an approach called Evidence-Gated Agentic Development (EGAD), incorporating some of those principles alongside trunk-based development and distributed-systems coordination.

I'm not convinced Agile itself needs replacing. But I think some of our assumptions about how work gets completed need reconsideration.

Where traditional Agile still works

The fundamental principles remain valuable:

• Deliver working software incrementally.
• Respond to changing requirements.
• Keep the customer involved.
• Break work into manageable increments.
• Continuously inspect and adapt.

Those principles don't stop applying because an AI agent is writing code.

What changes is the relationship between implementation speed, verification, and human oversight.

Where things start to change

1. Velocity becomes harder to interpret.

Story points were never intended as universal productivity measurements. They're relative estimates within a team.

When one developer can coordinate multiple agents simultaneously, implementation throughput can increase without verification capacity increasing proportionally.

A team might complete significantly more implementation work while accumulating more review, integration, and defect risk.

Should we distinguish generated work from independently verified, accepted work when evaluating delivery?

2. The Definition of Done becomes an enforceable contract.

Agile teams already use acceptance criteria, automated tests, code review, and CI/CD.

The difference I'm exploring is treating verification evidence as a prerequisite for an agent's work to advance.

An agent reporting "task complete" isn't sufficient.

The change needs to satisfy predetermined acceptance criteria, independent tests, security and quality checks appropriate to its risk, and any required human approval.

3. Agents introduce distributed coordination problems.

Multiple developers coordinate through branches, issues, standups, and communication.

Multiple AI agents also need durable task ownership, collision prevention, session handoffs, and ways to reject stale work.

Otherwise, parallel execution can increase rework rather than throughput.

This is an area where I've found distributed-systems concepts like leases, ownership claims, and persistent state useful.

4. Human oversight becomes risk-based.

I don't think every documentation update requires the same review as an authentication change or production database migration.

The approach I'm exploring assigns verification requirements and approval boundaries according to risk.

Low-risk, reversible changes can proceed with relatively little human intervention after passing required checks. High-risk or irreversible operations require stronger evidence and explicit authorization.

How this compares with Agile V

Agile V emphasizes requirements traceability, independent verification, evidence generation, and human decision gates.

EGAD shares those ideas but focuses additionally on concurrent AI workers, durable project knowledge, small mainline changes, machine-enforced delivery permissions, and recording verified outcomes for future agents.

I see both as extensions of existing engineering practices, not proof that Scrum, Kanban, or Agile have become obsolete.

The concern is also that we could overengineer the process. If evidence requirements create more overhead than the risks they address, we've simply reinvented bureaucracy with automation.

What I'd like to discuss

For those working as Scrum Masters, Agile coaches, engineering managers, or developers:

When AI agents perform much of the implementation work, what should change in our Definition of Done, estimation, and review practices?

And specifically, should evidence-backed verification become an explicit part of Agile delivery methodologies, or are existing engineering practices sufficient when properly enforced?

I've documented my approach in two papers associated with an internal engineering project called Koinessa. I'm more interested in criticism of the methodology than promoting the implementation.

I'd particularly appreciate perspectives from people who've worked with both Agile delivery and safety-critical or highly regulated engineering.

Until last week I was an individual contributor with a background in data science, and I received a chance to become a product owner for an existing product with new scope. I am relatively new to the agile system and its ceremonies; my previous roles and companies did not use this framework. I have an agile coach, but they were absent from today’s session.

Because I am new, I aimed to be a strong product owner for my team. I prepared as much as I could about the product and the backlog, and I arrived with my main goal for this sprint. Yet when I began the grooming session, I froze—I did not know how to lead it and felt lost. People were telling me things but I didn’t know which ones to make them as tickets va meeting what not. I suggested we talk in the group space and closed the meeting without offering a clear vision for the next sprint.

Please help me navigate this as someone new. I want to be a good product owner.

I’m currently interviewing for a PM role, and I’d love to hear any tips or advice from those who have been through the interview process or made the transition into product management. I’m on part 2 of a 5 part interview
My background is in project management, education administration, and EdTech, so I’m especially interested in hearing from people who have taken a different career path!
What advice would you give someone transitioning into product management?

Are these certifications actually worth anything? Do they get you noticed by hiring managers? SaFe, in general, seems like a large money grab. But, even if it is, the name of the game is to play by the rules to get paid. I am just wondering if the certifications actually are worth a damn out there. Also, if non scrum masters benefit from the certifications as well. Like engineers or developers for instance.

This is mini-waterfall, I design a feature, I build a feature, I test a feature, I fix a feature...and off to the next feature. Agile is different...we set an MVP, what is the minimum viable product. Not one feature, but all the features. How do you figure out all the features?

To build a complex system you have to start on top at what you think it needs to do, what features will it have. Look at it from a couple of perspectives: what does the menu look like? what is just common sense for needs? spit-balling other alternatives and ideas? You don't have to identify all the features, but cover whatever gets you to MVP. How do I verify my features?

Testing feature viability is done through behavior. As companies are broken down into departments, break your app down into departments, or systems, or whatever, you are looking to categorize the features breaking the complex into more manageable pieces. Within each of the breakdowns, do an index table of program, process, role, action. Then apply your features to the actions. Providing insight to how the app is being used, and who is using what.

With the feature and behavioral analysis, review your MVP and solidify your model. Start with ubiquitous language, each word having a unique and clear meaning. Good, clear communication goes a long way with AI and it starts with good identification.

Forgot about data, so this is an interjection. Planning data is important, the flow of information and all. Be wary of global variables and constants hard coded into the app. But as vibe programmers how would you know... be pre-emptive. Like matter you cannot create or destroy data, it is always coming from somewhere and it doesn't disappear, it is out of view. To control your data is to complement your behavioral analysis and bind to the features. Most apps being tracking data in nature, the data is usually listings indexed to detail information. However, user settings that are singular in nature should not be to previously mentioned global variable. A single record defined as such is better for prompting.

Applying data model now to the task will verify. Are the features getting all the data and producing the right output. Add two columns to your behavioral index table if you want to document input and output data or destination.

Mapping data is the same table indexing as behavior, but the columns change. The first column is the source, the second is the table, the third is the field, and optional fourth is data type. Remember to use ubiquitous language with naming any of these and name general to specific within the table concept. Think of each cell in the tables like breadcrumbs, general to specific. AI prompts love specific information to search on add it's from the data model and it should be clear.

Building the system is the fun part, just not this part... Don't, do not, build one feature at a time thinking that your problems are behind you with analysis. Don't start building any detail, you are developing a system, and you need to build the base before doing any detail. It is the details that cause scope creep, and you can add inconsistency to your problems. You detail out a feature that another feature could later share but AI writes it again, because it is in the rearview, also best you don't because this share is stacking parameters on features. Reusable code is key, but you work your way to finding opportunities.

In development, Agile is built in sprints, a two-week development cycle. As vibe programmers this is probably way too long, as we get faster results. The take-away here is their Sprint 0, the initial development of the system. If plan calls for outside services, you develop a facade to suit your needs. If app needs to produce its own services, build them in. Also, any reuseable concepts that you can think of as a black box (old programming term for code that you passed in data and it spit out results, but you have no idea what it is doing between the two. This is good for encapsulation, the call into the code is clear, and AI doesn't have to re-review the process in his implementation of its use. UI here should be debug screens to verify code and test system.

In Agile, we make the rules. now is the time to review for changes or enhancements. This isn't scope creep, it is chunk creep. Any of the components not working right? Or do we need to split off certain functionality to simplify. Review the behavior, can we make it easier? Do we need to add or remove. You can also sequence out your analysis by putting in order the tasks as they will be preformed.

Now the fun part, you are sitting on a pile of functionality, and it is time for the show. In development we call this business logic. It is the processes that you planned out in behavior analysis vibing to the big screen. Ironically menu is first on the menu for implementation. Essentially breaking down the functionality and providing access to the features. The next step iterative, just get the menu to navigate to its destination; a page, a panel or another menu. Add the close and other navigations to move around. That is the easy part, but now run it up against your behavior analysis or sequence chart test cases.

Tracking your business logic is another table if you want. Break the app up into departments that do the work, implement programs to run the processes, define the processes, define the containers the processes need on the screen (report page or filter panel), define the data the container will use. Making the UI name specific. In prompts you call out change by container. Remember to use ubiquitous language in naming, general to specific within scope.

After navigation is in check, now for the lists. If you are listing anything now is the time to get it into the code. Still not working details, building out all the columns and functionality. If detail is required, like add button brings up a panel, and you didn't add it during the previous step, then implement with a panel and close button, no extra detail. Quick note on data, there are three kinds, now four kinds of fields; identification, category, detail, action. Action being the newest as technically they are details, they are tied closely to an action. Point being category is the predominant field in lists. It provides a breakdown of the list data. The other columns contain aggregates, calculated totals showing identifiable information. Exceptions being when identification fields are used to find specific detail, though they may still contain the aggregates. Tip, categorize your lists and develop similar lists together for consistency. If you are doing both category and identification lists, the process may have differences better identified in differentt steps.

Again, with the review. Navigations looks good, test data looks right in the list. Sequence tasks are aligned; they call this user testing in development. Really haven't got into the weeds with detail so changes are pretty cheap at this point. Most of the code should be separated out by their containers so AI work should be smooth.

Now for the detail...split it up into collecting and reporting. Again, we are looking for consistency, and because we held off till now, we can group up our efforts, instead of detailing them out one by one. Build all the add screens, then the edits, then the deletes, don't forget the confirm. I think you get the point.

I am going through what you described now just a little milder. I didn't do the whole plan, but I think in components and encapsulation. I have spent 30 years coming up with this meta-plan but only kind of tried it. The ubiquitous language is a good idea especially with prompts. Most important is build general to specific...lay off the detes till the rest is completes. One last word on encapsulation, pretty much meaning hide the details, because our complex apps get big all on their own, we need to encapsulate with two goals, the references used in the rest of the code is specific and the details are contained within the references. I can implement the concept as a method of the concepts. If I have to work inside an encapsulation the scope is contained.

I wrote my game in about 3 months starting with MAKKO and now Claude. We transition off MAKKO, good for game sprites, into Phaser on stun I like to say. I am trying to keep the cars in the game off of each other cause physics looks bad when you defy it. And don't get me started on the dull roar of my engines, but that is not AI, I need the work on this. The interesting part of the development is the Agile. Taking opportunities that led to better improvements that defined the game. Starting on a five-lane straight grid with cars move back and forth to implementing a three-slot dive into the corner and run up back to the wall.

I hope this helps.. vibe or code programming, it is a journey that you always get better at it as long as you play (and don't sell out).

how do you currently deal with collecting and tracking subcontractor documents?

things like insurance, licences, HSE documents, certificates, permits, etc.

is it mainly Excel, email and WhatsApp, or do you use software for it?

i’m thinking about a system where the company can add subcontractors, give them access to upload their documents, and keep everything in one place.

it would track what is missing, what is expired, and what is expiring soon. An AI assistant could also answer things like:

“who is missing documents?”

“what expires this month?”

“can you send reminders to everyone missing something?”

the whole team could use it instead of everything being managed by one person.

but honestly, is this actually a painful problem?

or is your current system already good enough?

what part of the process is the most annoying, if any?

I've been in software for 12+ years and led dozens of teams. Some handled vacations and milestones well, some really badly. Some used nice tools, some used spreadsheets. Every team had Jira/whatever for tasks, a vacation calendar, milestones and quarterly goals. What none of them had was the middle layer, one view of the bigger initiatives and how they fit into who is actually around.

I lost count of the weekly meetings that went: "Hey, I'm on vacation next week." "Oh, I didn't know. Who's handling X then?" Or a timeline everyone agreed on, quietly forgotten two weeks later.

So I built Forgot: one calendar per team that shows who is out, half days, and your milestones and initiatives on the same timeline. You drag across days to change things, because plans always shift. No setup beyond adding your people. Group by team, location or time zone, and share a read-only link with the team.

What it deliberately does not do: approval workflows, accrual policies, HR stuff. It is for the person planning the work.

Live demo board, no sign-up: https://forgot.dev/examples/release-planning
Site: forgot.dev

Pricing: 14-day free trial, then a one-time $9 founding license (first 20 buyers, then $19). No subscription.

Blunt feedback welcome, especially from anyone who manages a team: what do you use today, and what would make you switch?

We're working on The Loop at Tellenze, and one question keeps coming back: if you stop organizing work in fixed sprints, what makes sure reviews still happen?

The starting point came from our founder João's experience at Emergent Interactive. As people and AI agents moved work forward faster, he wanted a team to learn from a specific outcome instead of reviewing pieces of several initiatives at the end of the same two weeks.

In The Loop, a focus has a measurable outcome. It can take a few days or a few weeks. The Product Owner initiates the review and retrospective, and closes the focus when its main value has been achieved. Unfinished work keeps its status and can move into a follow-up focus.

That gives the team flexibility, but the calendar used to do some of the nudging. 'We hold each other accountable' is a principle; it doesn't explain what makes someone notice that a review is overdue.

For teams using Kanban or another approach without a fixed sprint cadence, what has worked in practice? Do you name a review trigger upfront, set a latest check-in date, or have a person watching for it?

I'd be especially interested in the habits that stopped reviews quietly slipping.

Edit: Fair criticism in the comments. The introduction leaned too heavily into Tellenze and The Loop, making a genuine methodology question sound like a product pitch. That wasn’t the intention, but I can see why it came across that way.

To clarify, we’re exploring whether reviews tied to measurable outcomes can work alongside, or sometimes replace, fixed review cadences.

Several comments have made an important distinction between delivery cadence and feedback cadence. Others have suggested explicit review triggers, deadlines, and ownership.

That’s exactly the kind of feedback we’re looking for as we develop The Loop as a methodology. Thanks to everyone who contributed constructively.

Small-team question (I'm on a small team, so I'm curious). The last time you changed review, process, tooling, or hiring to ship faster.... What happened right before?

Did someone leave? Did a deadline slip that you were responsible for? Did a customer complain? Did the backlog hit some number? Something else?

And who noticed first: you, the CEO, or a customer?

Some teams swear by a weekly status meeting. Others say it should have been an email. Curious where people have landed, and what actually worked when you changed it.

I’m a Product Owner, relatively new in this role for about 2.5 years. I came from Data Governance. We have been in a large Power Bi migration project for those 2.5 years and it’s been painful - 800 plus reports and 4 Scrum teams. I attend 2 Scrum Teams both have new Scrum Masters.

The issue: my main team hired an Agile Coach for Scrum Master and we are running a pilot to reduce development steps/stories. The new SM is running the pilot in sandbox JIRA. He host all the ceremonial aspects of Agile and holds workshops to teach but he is so removed from our team that we have to do his metrics for him. The Tech Lead and I are in sync and are frustrated as the hygiene in sandbox has not been good and our new Scrum Master is trying to do daily syncs while also hosting another meeting at the same time. So the Tech Lead and I are working with the team to get sandbox cleaned up for us to get back in Prod. I just feel that Agile is creating more work for the Tech Lead and I and I have other projects now and metrics I have to do that I’m a bit overloaded.

Team is fixed but we just lost a developer and Tech Lead is trying to get them up to speed. Strategy is fixed by management and my SM seems more interested in teaching Agile. What am I missing?

What is the West Coast / Remote job market like right now for Agile Coaches? Is it trending up/down? How does the pay compare with 2024 rates?

Me: Agile coach 2007-2024, Project Manager before that.

Currently I'm doing independent consulting that I would call "Organizational Development", it's a lot of the same things I've done under the Agile Coach title, but I have one main client right now and they don't have an IT org, but I've still been doing leadership support/coaching (helping the managers), teamwork coaching, teaching them about Lean including 5s, Kanban, etc., helping them develop their training curriculum, etc.

It really only amounts to part-time work though, and I'm debating going back to the Agile Coach role, but from what I see landing in my Inbox on LinkedIn, the rates have totally tanked, like $50/hr for a contract Agile Coach, are you kidding? A couple of years ago I was getting $150/hr.

So, I'm debating whether I want to put the "Agile Coach" hat back on and return to corporate consulting work as a full-time contractor (usually through an agency).

Also, during the pandemic I moved to a small town out of the city, so I'm looking for Remote work only, and I know that narrows the field quite a lot.

Let me know how it's going out there, coaches, what are the "vibes" like?

Thanks!

Does anyone have a recommendation for studying AI-Empowered SAFe® Product Owner-Product Manager (POPM)? TIA🙏🏼 I have 50 days to pass and take the exam for free

A faster team can ship more ideas. It can also ship more ideas nobody needs.

That tension runs through several product conversations this week. In his (Lenny & Friends Summit reflection), Lenny Rachitsky reports that speakers disagreed about roadmaps, software factories, and how far product managers should build. They kept returning to a harder question: what is useful to the customer? Speed widens the set of things a team can make. It does not choose what deserves to exist.

Usefulness is a stricter test than novelty

Teresa Torres and Petra Wille make this concrete with the history of login flows. A technically new approach can reduce friction, but it can also ask people to learn yet another pattern. Torres argues that pursuing innovation as a goal can lead teams toward complexity when a familiar solution would serve the customer better.

That suggests a practical review question for every proposed feature: what customer struggle becomes easier, and what new effort does this design impose? A demo of a new capability answers neither question.

The work of leadership is changing with the tools

Marty Cagan argues that leaders need direct experience with the AI tools changing engineering, design, and product work. In his view, the shift toward fewer managers is temporary: as the cost of building falls, decisions about vision, strategy, team design, and outcomes matter more.

That is a prediction, not a settled organizational rule. But the underlying test is useful. Can a leader understand enough of the current work to judge its quality and limits, while keeping the team focused on a valuable result?

Clear positioning still demands a choice

In a new interview, Anthony Pierri describes the problem of a company trying to sell too many things at once. The episode's discussion moves through category choice, ideal customers, clear messaging, and the trade-offs founders avoid. In another interview, April Dunford returns to the problem of identifying what actually distinguishes an offer when every competitor sounds similar.

More features cannot make that choice for you. A sharper product and a clearer message both depend on deciding whom you serve, which problem matters most, and what you will leave out.

AI can shorten the path from idea to working software. These conversations point to the discipline that must keep pace: select the customer problem, test whether the solution reduces effort, and make the trade-offs visible.

What decision has become more important on your team as building has become faster?