This is the April 2025 Pragmatic Manager Newsletter, from Johanna Rothman. The Unsubscribe link is at the bottom of this email.Early in the agile community, people referred to the Product Owner as the “single wringable neck.” Somehow, if the product owner didn’t define the stories well, or create acceptance criteria, or even represent what someone […]
I discussed how to calculate the Costs of Delay in the previous three posts, and then offered an example in Part 3. Notice that the example uses cycle time or how the team feels about the remaining time to think about the value in order to rank the work. (The links to all the posts
Ranking work, whether it’s for the backlog, a roadmap, or the portfolio, sometimes feels like throwing darts and hoping for the best. But especially if there’s too much work and a lot of WIP, we have a tool for clarifying that ranking—the Cost of Delay. It does require counting the number of people and easy
Ever since I was on the Troubleshooting Agile podcast, I’ve followed Squirrel and Jeffrey. (I highly recommend their podcast.) Recently, Squirrel posted something fascinating on LinkedIn: Aim for a “single source of lies” about your business. That’s quite a provocative idea, especially when many of us persist in looking for a “single source of truth.”
Recently, a newish site asked me to become part of their “editorial board.” They didn’t say what the responsibilities were, so I asked. The reply: Spend five hours a month in meetings (roughly an hour each week). Write a new, unique column each month. I asked what I would get in return. Nothing. No payment
When I saw the McKinsey report on “developer productivity,” I shuddered. First, that makes no sense in a collaborative team. Second, there’s no way to measure such a thing as developer productivity, despite what McKinsey says. (I’m not linking to the report, because the advice is so bad.) Then I read Lorin Hochstein’s brilliant assessment
Product owners have many challenges: They need to keep at least two thoughts about the product: what it needs to be in the near future, and what the organization wants it to be in the (distant) future. Some product owners think they’re supposed to fill out a complete backlog, including all the UI designs for
Much of my LinkedIn and Twitter feeds have questionnaires with two or three choices. One of those choices contains the One Right Answer. All the other answers are Wrong. Or, a person poses a question that’s supposed to show that they—and they alone—know the answer to the question. (I ranted about one of those on
I started this series with the issues of trying to estimate/predict a specific backlog item quarters away, not even weeks away. (Even weeks away is iffy because the entropy is the default state for the world.) In Part 1, I suggested that the team can use cycle time, but even with cycle time, we need
In How to Predict When the Team Will Complete a Specific Backlog Item, Part 1, I said there was no way to accurately predict an estimate for a specific backlog item more than a month away. I did suggest several options if you want to go through the motions, but there’s no accurate answer to