I have Peter blocked, so can’t quote him directly and won’t respond if he injects himself into this thread (he usually takes my tweets out of context and quickly resorts to personal attacks), but his tweet (see screen shot) is an interesting list, so lets’ go through them: 1/11 
"Dispense with measurements…" In general, when I go into an org, measurements won’t help with things that are most wrong. Things like no psychological safety, a culture of competition vs. collaboration, a culture that puts process over people. 2/11
Measurements are useful for tweaking things once the worst problems are addressed, but most orgs never get to the point where the worst problems are addressed, so there’s not much value in measuring. 3/11
"Why estimate at all?" Why indeed? I see little value in the practice. That’s a huge topic, however, which I can’t cover in a tweet. The gist is that if you’re constantly learning, your estimates are always wrong, and are in constant need of rework/adjustment. 4/11
That’s classic waste in the Lean sense. There are other was of planning that work better, IMO. 5/11
Story points do do actual damage IMO, particularly if they’re turned into "velocity" and used to bludgeon the team into overwork or used for comparing two teams. Again, there are better alternatives. Take a lean approach: measure the work rather than estimate the stories. 6/11
Planning poker is certainly nonessential. If your stories are all small, then you can just count. If your throughput is 3 stories/sprint on average, then just pick the top 3. There. You’re done. Working on making the stories small _is_ valuable, however. 7/11
Most of the alleged benefits of estimation (e.g. thinking about the problem) are also present, if not more so, in the story-narrowing process. All you need for planning poker is estimation.lunarlogic.io 8/11
I don’t see much benefit in Sprints. Just work on the most-valuable story. When you’re done with that, go pick the next most-valuable story. 9/11
It might be valuable to have various review cadences à la Kanban, but I see little value in putting all review actives into a single cadence. 10/11
Code reviews are indeed a waste of time when you work in a way that doesn’t require them. For example, if you’re mob/ensemble programming, you’re reviewing as you’re working. A separate code review step is unnecessary. 11/11
• • •
Missing some Tweet in this thread? You can try to
force a refresh
