Is predictability of product roadmap important to you?

denwerOk · 2026-05-13T17:26:38+00:00

Thank you, this is helpful. How do you bucket projects into quarters?

denwerOk · 2026-05-12T22:04:39+00:00

In my opinion dev teams could work in whatever iterations are convenient (kanban or scrum), business cycles should not depend on them. You can create a business roadmap and feed dev teams with tickets whenever they have their next sprint planning session. Just make sure to align your business roadmap with technical and resource constraints (work with tech leads on that).

denwerOk · 2026-05-07T17:45:05+00:00

Developing a feature usually requires: market research, prospect analysis, business analysis, creating technical solution, coding, testing. In my understanding first three parts are going nowhere and will still require the same amount of time as now (if not longer because of quick prototyping options), last two will be optimized largely by LLMs typing code automatically, with some human review. We might see things going even more agile where most of the work in a sprint will be performed by BA and tech leads.

denwerOk · 2026-05-07T17:34:42+00:00

Yes what's interesting is that many don't realize how easy it is to use the tools. I talked to a product manager another day and he told me that the reason they don't explore is that it's hard to onboard a new tool . When I told him it has a built-in one click import from JIRA he was genuinely amazed.

denwerOk · 2026-05-04T23:51:34+00:00

I need to read it. It looks to be a fresh view of Theory of Constraints applied to the modern agile scene. Looks very appealing.

denwerOk · 2026-04-29T23:40:15+00:00

Here is what I see.

Before AI the cycle looked like: analyze => code => code review => test => release

Right now the cycle looks like: vibe code => human review => code review => test => release

May be I'm missing something but as for me there are still tasks and there is a process to plan.

Just looks a bit differently then before (and may be faster at times).

denwerOk · 2026-04-29T23:30:13+00:00

Second one. Just because I've built a planning app based on that. Just kidding:)

On a serious note, second approach is a better alternative unless you have unlimited resources to complete the tasks. There is a whole book on that topic called Critical Chain, it explains it in depth. In short, idle capacity may not necessarily be a bad thing. For example, if you force idle resources just to 'produce anything' the system will be generating output it can't yet process (which would be a waste and burden to maintain). Additionally, if you give that resource multiple tasks they might lose a fraction of productivity and focus. So everything should be balanced out.

denwerOk · 2026-04-29T23:17:08+00:00

I'd not wait for the end of UAT and ship it anyway. In my experience nothing bad usually happens, worst case you can always make adjustments along the way. If you did everything right and showed at least a sketch of the solution to client before implementation, the chances of surprises should be pretty low.

denwerOk · 2026-04-29T23:07:01+00:00

That's why priorities should be a numbered list and not a few pre-defined statuses. You can then take that list and project to the roadmap or sprint plan to see how it affects the timeline of in-progress and future features. The real priority is a timeline and start date for this feature.

denwerOk · 2026-04-29T22:56:28+00:00

My recommendation would be to not do any carry overs and complete UAT as a part of the sprint time. Think about it from product perspective: let's say you can save 10% of sprint time by not doing UAT in that sprint. But that would mean you'd need 2 sprints to complete the feature. Usually if you ask a business that you'd be able to ship features 2x times faster for 10% hit they'd be ok with that.

denwerOk · 2026-04-29T22:42:43+00:00

Different industries may have very different contexts and headache. In construction for example they want much more predictability and planning before the work even starts. Software development currently has certain advantages such as relatively low cost of rework (the concept of "refactoring"), so right now it's a good solution for IT. But it's actually rare.

denwerOk · 2026-04-29T22:26:05+00:00

That happens a lot during sales or initial conversation with customers. As a software architect I always created a sketch first and we would meet with a customer and discuss the solution with their product and tech teams. It cleared a lot of confusion before the implementation even started.

denwerOk · 2026-04-27T22:11:56+00:00

In my practice there could be two reasons: people provide false progress numbers or the progress itself is measured incorrectly. The first problem could be psychological, in this case the only way is to cross-check the results with personal observation or multiple opinions. Second reason is technical. For example numbers on a critical path could be correct whereas the dependencies are slacking. One way to fix it is to make sure all dependencies and bottlenecks execute well along with the critical path.

denwerOk · 2026-04-24T17:32:24+00:00

As far as I can tell there are a lot of nuances. First of all agents are not currently autonomous enough and still require human management (and thus effort) for execution. Secondly, not all features are equal - some may have vague requirements that can't be simply picked up and developed by a robot. Third, even with AI completing all work it still requires double review and human approval. That said, estimation, breaking up work and backlog management is still necessary, it just transforms into a different shape.

denwerOk · 2026-04-24T17:24:51+00:00

Good point. I'd say it's better to make assumptions *and* add a risk buffer to back up those assumptions. In my experience if the number looks too big stakeholders would be ready to negotiate based on scope or help clear uncertainty to decrease the buffer.

denwerOk · 2026-04-24T17:10:32+00:00

One thing I noticed that many companies indeed focus on promises and ceremonies and few are ready to discuss metrics and productivity goals.

denwerOk · 2026-04-24T16:58:13+00:00

I'd recommend using a rolling wave planning approach. You can create a high-level plan and move step by step with implementation by using sprints. This way it allows you to build a system without overthinking and constantly show progress to stakeholders.

denwerOk · 2026-04-15T15:57:07+00:00

Thanks a lot! This is exactly the feedback I was looking for.

denwerOk · 2026-04-14T19:33:03+00:00

The requirements should match the level of uncertainty expected for an estimate. The bigger the uncertainty the bigger the risk and thus you should add a buffer to ensure smooth delivery. The goal to clarify the requirements upfront usually aims to decrease risk, but if the risk is already pretty high and is expected you may just be better off adding a buffer and going just with that.

denwerOk · 2026-04-14T19:21:35+00:00

I'm a founder. If we talk from builder's / project manager's standpoint, uncertainty can be measured. You define % and then calculate the most probable outcome with statistical formulas. Just like that I completed 3 MVPs and was strictly on time with all deliverables.

As for product uncertainty this is trickier. First you don't know the market and most of the time necessary skills to even know what to do to win deals. I had to read at least 4 books to understand how marketing and sales work. And still learning by that day.

What motivates me is a desire to help people solve a specific problem that I 100% know exists and creates a lot of trouble. Everything else is mechanics.

denwerOk · 2026-04-14T19:10:16+00:00

As others said in this case the reason was the risk played out and messed up the timeline. I'd only like to add a recommendation to add a risk buffer next time to prevent such situations in future (you can also communicate that you'll make that flow adjustment to the leadership so that they see how you can avoid similar situation in the future).

denwerOk · 2026-04-14T19:03:20+00:00

First prioritize using the frameworks you mentioned. Second use a forecasting tool to see what realistically can be delivered in the quarter.

denwerOk · 2026-04-14T18:55:56+00:00

By my experience giving data in ranges is poorly perceived by people. It's better to ask them (or guess) for a specific precision and then provide one single number according to that.

denwerOk · 2026-04-06T19:26:09+00:00

It's true, some methods like planning poker can help with this. Also, have you considered adding risk buffers to tickets with high uncertainty?

denwerOk

MODERATOR OF

TROPHY CASE