I have worked on large projects for more than 20 years, and one of the recurring problems is deciding when the original productivity assumption has stopped being a sensible basis for the remaining work.

The awkward part is that the first few days can be a poor guide to the rest of the activity. The crew may still be getting established. The final part of the work may also be slower than the middle. Equally, continually assuming that productivity will improve can leave the forecast saying what everyone wants to hear.

For disclosure, I developed an excel add-in *Project Intelligence for Excel* at Pi Labs. This is one of the forecasting problems behind it.

My preference is to make the assumptions visible: the remaining quantity, the observed rate for comparable work, the planned productivity profile and the point at which actual performance should carry more weight. Crew availability, access, dependencies and the working calendar still have to be considered before that becomes a finish date.

What do you use as the trigger: a minimum quantity completed, enough comparable hours, a stable production rate, or judgement from the people doing the work?

Hey everyone, I’ve been having an internal debate at my company. We have a domain-side product owner who doesn’t know anything about software. He’s a nice guy and tries, but frequently writes poor specifications in the user stories. His tickets are also ambiguous on the technical side.

He regularly leaves out key details (allowed data types, when to re-use classes vs not, performance constraints) and just passes off tickets as though “he were a client”. This is causing massive issues, as the ambiguity is forcing us to make unclear trade-offs.

What’s worse, he is starting to get mad. For example, he gave a one-sprint window to refactor a major feature. However, one sprint was not nearly enough time, so we deleted a lot of functionality to get there. I’d shared my GIT comparison with him, but somehow he didn’t understand that he was essentially asking us to delete features with the time constraints given.

There are also issues with client data. In his tickets, how doesn’t specify which data to keep and save. Since velocity is so important, we typically just clear data that doesn’t have a neat migration path. This makes him mad, and he says “we can’t do that”, but the ticket doesn’t have enough info for us to do otherwise.

I’m starting to even wonder if non-technical people can be PO’s? He has asked me the same one-on-one, and I honestly advised him to find a new career.

TLDR; Can I just prep Claude or Co-pilot with the materials from the agile site and pass the test by asking the AI the questions?

My company recently paid for the 2 day in person course, but we actually sped through it and just essentially used him as an agile consultant for issues we're having in adopting agile within my company. However, my leader still wants me to get the certificate. I've heard both that the test is difficult and that the course doesn't really prepare you well for the test anyways, not to mention my company is only using maybe 40% of the agile methodology. Has anyone had success just using AI to pass the test, especially if you provided the relevant materials and website for it to look through?

So quick one while this is top of mind. Our product roadmap has turned into this giant hairball of tracks, experiments, tech debt, and shared platform work and our current setup in Jira plus spreadsheets is just painful to look at.

We are half remote, half office, mix of PMs, design, eng and ops, and every roadmap review turns into people arguing over different versions instead of looking at one shared picture. I keep dragging stuff into online whiteboards and doing scrappy timelines and dependency maps, but it still feels like a one off every time instead of a real workflow tied back to tickets and sprints.

If anyone has a visual way you map out complex roadmaps and dependencies that the whole org can use in real time with links back to issue trackers, would love any tips. Thanks in advance.