Flow Metrics Book Review
Tags: agile, estimation, software
Published: 2023-02-07 13:53:26


---
title: Flow Metrics Book Review 
published: true
description: Book review of Flow Metrics, how you can utilize Monte Carlo Simulations to estimate how long your software project takes.
tags: agile,estimation,software
canonical_url: https://jessewarden.com/2023/02/flow-metrics-book-review.html
cover_image: 
---

I read a non-fiction book. I never read whole non-fiction books, usually skim the “good parts”, ignore the rest, then tell everyone the book rocks. Unclear why I powered through this one.

It’s called [Flow Metrics](https://prokanban.org/%20scrum%20flow%20metrics/), it’s free. It + some associated blog posts answered a lot of questions I had around the factions of “story points are trash”, Agile No Estimates, and No Sprints. [Eric Fahsl](https://www.linkedin.com/in/ACoAAABLauIBlF0R1Yo9EMZVgIzVG1nEjgRpGuA) told me about the no estimates crowd in 2015, but for whatever reason I couldn’t find anything on Google/Twitter back then. It also made me feel better that I didn’t waste my time in the early 2,000’s reading all I could about Agile/software project planning.

There were 6 big takeaways.

First, many of Agile’s original creators think story points/t-shirt sizes are worthless, and have data to prove it. Instead, you use Monte Carlo Simulations to provide more accurate forecasts for your Scrum or Kanban projects. This means 80% of what you’ve been doing stays the same. Good news, right?

Second, if you intentionally ignore the “all stories should be 1 point” extremists, Flow Metrics still provide accurate forecasts regardless if all stories are of various sizes.

Third, the existing/default use of averaging story size per sprint to provide projections is just bad math, and they give examples you can try.

Fourth, story sizing from the user value vs. tech stack is hard and awesome. Time and time again I work with teams that either don’t know how, or do but intentionally do not, check in many small changes vs. 1 large, gigantic/risky commit/PR. Doing the opposite approach is wonderful, but I question if existing teams who can’t even split the work could event attempt to split the user value.

Fifth, it’s easier to do all this if you’re full stack, or you ensemble program with non-cross functional people (some awesome DBA women + rad API guy + some UI cat), else there is a lot of coordination.

Sixth, I struggle to see how \_any\_ of this works without trunk based dev & a strong CICD (specifically the CD part) culture.

I encourage you to look at the 2 images (most viable products) I’ve attached in the first comment, then re-look at them with fresh eyes after reading the book. It certainly changed my perspective. I wish I knew this crap in my 20’s.

This meta stuff that ignores tools and programming language choices I love because you can use regardless of where you work. I’ve included supplement blog posts that can give additional context from the book. Highly recommended read.

Book: https://prokanban.org/%20scrum%20flow%20metrics/

\#NoEstimates and #NoSprints: https://medium.com/codex/noestimates-and-noiterations-2b5df43d8c34

Splitting User Stories: https://medium.com/codex/splitting-user-stories-20475cb1769b

Estimate Pi with Monte Carlo Simulation in JavaScript: https://questsincode.com/posts/monte-carlo-simulation-javascript

Here are 2 classic images (I can’t remember which book they’re from). I look at these with a completely different perspective now.

![](https://jessewarden.com/wp-content/uploads/2023/02/Making-sense-of-MVP-.png)![](https://jessewarden.com/wp-content/uploads/2023/02/1-E0vHf9pR5FjeFbbRq4pMSQ-1024x576.png)