If you're asked a broad project estimate, building a very fine grained user story list is likely not the best approach.

If you spend your time in dull meetings and then run like a headless chicken... it's definitely a sign you should cut down on the meetings and keep only the ones focusing on solving actual problems.

Good approach to detect problems early and manage the risks they'll bear.

Interesting thinking around a portfolio of activities. You can prioritise differently within it to manage quality vs speed of delivery over time.

Or why it can be dangerous to label medium the high likelihood low impact risks and the low likelihood high impact ones. One category is to be completely avoided while the other brings learning opportunities.

Or why you can't consider risks in isolation. It's too often forgotten.

Interesting extra dimension to think about risks. I don't think I ever encountered it in the wild but that can make sense to use it.

Struggling with making your first technical roadmap? Driving it from measurable problems is a good first step.

I don't exactly use this approach to factor in the uncertainty... but I guess there's something to be made out of this proposal. I'll keep it in mind for my next project.

Excellent article introducing how to analyse risks.

This is accurate in my opinion. Engineering and product teams need to properly negotiate, otherwise quality will suffer.

Interesting guidelines idea to help teams manage the priorities themselves. It's written in the context of a product manager but I think it is lightweight and generic enough to apply in other contexts.

We keep saying they're not the same. This article does a good job highlighting the differences and explaining why you need both.

When I read the content of this article I wonder how useful the metrics really were. I mean clearly they helped the team realize which changes to bring... but the practice changes were all somewhat conventional in a way. You go a long way when you focus on quality and create the space for it.

He is spot on again. The scope is what will allow to create flexibility in a fixed price project. This is what leads to the necessity to work incrementally.

A bit long and a couple of mistakes when pointing out the flaws of story points. Still, it's definitely a worthwhile read. Quite a lot of the criticism of story points is warranted and the proposed approach based on queue theory is welcome. This is stuff you can find in Kanban like approaches and mature XP.

A nice collection of versioning schemes. I definitely didn't know them all.

Interesting musing about the concept of friction in strategy. There are indeed a few lessons to learn from it in the context of software projects.

This is definitely an ambiguous term. You need to know where stand the people employing it in order to figure out the exact meaning of "root cause".

This is indeed an important aspect of estimating work. The smaller you manage to break down tasks the easier it will be to estimate. Breaking down work is a skill in itself though.