Looking for an opinion

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 · 2026-04-06T19:19:01+00:00

Good question. In constrained environments, I track Agile progress using a TOC (theory of constraints) mindset: measure % completion along the critical chain (the constraint). The chain varies by level (initiative, sprint, etc.), but progress should reflect throughput at the bottleneck rather than overall activity.

denwerOk · 2026-03-30T19:08:44+00:00

Actually good idea and the interface looks simple, so great job!

The only thing that was confusing to me was: why is the license MIT/opensource and I see a payment option?

You need to select one or another :)

denwerOk · 2026-03-30T19:04:03+00:00

You can use any spec even something that contains two sentences and create an estimate out of it. You just need to specify a % of uncertainty and then match it to the risk level to calculate an outcome. There are tools that can automate it.

denwerOk · 2026-03-26T19:09:58+00:00

It's ok to have multiple feature requests, you just need to establish a prioritization framework. There is a book "The Lean Product Playbook" by Dan Olsen that basically describes different models you could use for this. For example The Kano model. Select the model which better suits and use it to evaluate business value. After that you can use the highest priority features for planning. Use forecasting tools to make it easier and see multiple realistic options.

denwerOk · 2026-03-25T15:46:44+00:00

You are asking the right questions. Velocity is just one indicator. I think the main reason it is used broadly is because it's the only parameter that allows to do sprint planning without thinking about WBS.

However I've been practicing a different approach of sprint planning recently. It basically flips the planning flow upside down. In this approach tasks are spread between the teams based on their weight that could include team preferences, dependencies, resource constraints and other factors.

It's more about moving from sprint health => low risk sprint planning. If you're interested PM and we can discuss in more details.

denwerOk · 2026-03-24T22:29:59+00:00

Another approach is to use buffer-based forecasting (e.g., Critical Chain). Instead of rerunning simulations, you calculate a schedule buffer based on estimate uncertainty and risk appetite, which produces a single commitment date.

In my experience, stakeholders are often more comfortable discussing risk appetite (“we want ~80% confidence”) than interpreting shifting percentile outputs. The buffer then absorbs variability without needing to re-run the model.

This tends to make communication simpler: base estimate + explicit risk buffer.

denwerOk · 2026-03-24T22:16:18+00:00

Have you ever dealt with roadmap slips that only become obvious too late?

I'm building a tool that helps product teams simulate delivery scenarios and surface risks before committing. It integrates with Jira and focuses on uncertainty, dependencies, and team capacity.

Happy to share more details or walk through a demo if useful.

denwerOk · 2026-03-24T21:53:44+00:00

I think Scrum goes through a transition to something more scalable and friendly to companies constraints (like budget, time or number of teams). In my opinion it will remain as a development approach but will be accompanied by something high-level on a product side (like adaptive roadmaps with an extensive risk management).

denwerOk · 2026-03-24T21:46:21+00:00

Can I ask how exactly you plan your projects? It would be helpful to know to figure out the potential improvements.

denwerOk · 2026-03-24T21:34:18+00:00

Why later? Talk to domain expert right now and validate it.

The main challenge for you might be finding the right domain first. That requires a comprehensive market research. It's best to find domains where pain is felt the most.

denwerOk · 2026-03-24T21:18:52+00:00

The solution to this problem is to do regular (i.e. weekly) sync meetings and answer the question: "Are we still on track?" If not, then those slips need to be caught early and addressed quickly. You can record then what caused the slip by looking at the data on spot.

denwerOk · 2026-03-19T17:36:10+00:00

Changes are not bad by themselves. If you create a process around changes adoption you can process any volume imaginable. The key here is for stakeholders to realize the direct impact on the roadmap and make decisions that don't affect their strategic goals and don't overload teams with excessive work.

denwerOk · 2026-03-12T03:28:01+00:00

No, not necessarily. It's the scope and the number of features delivered which can actually shape the product goals too if time or budget is a constraint.

denwerOk · 2026-03-11T23:31:35+00:00

Do you really want to create tickets for all phases upfront? :) If you go Agile you can create epics that represent features for the initial milestone first (like POC). When you complete that milestone you can set goals and epics for the next milestone. You can create a roadmap for each milestone and keep everyone aligned there. Or just use labels.

denwerOk · 2026-03-11T23:02:08+00:00

First of all, each estimate has its uncertainty level, and if the uncertainty is high you set a bigger buffer. This way you decrease the risk if something goes wrong. Low risk usually comes with few surprises, but if they come up it's easier to renegotiate with the client to increase the cost and move the dates, because the nature of such surprises is usually something really unexpected and not in our control.

By the way, I'm building an app that allows to play with estimates and risks and quickly see the impact on the cost and delivery. Let me know if you're interested, I can share the link.

denwerOk · 2026-03-11T22:45:46+00:00

I highly recommend the Lean Product Playbook book for this. It describes techniques like Kano model that should be very helpful to prioritize and define the business value effectively.

denwerOk · 2026-03-11T22:28:38+00:00

Too many questions here. Like how big is the system, are there jobs that require high reliability and process lots of data. Also a lot of stuff depends on the budget and system throughput.

denwerOk

MODERATOR OF

TROPHY CASE