I have three official scrum master certifications and trained in a dedicated one week course under Ken Schwaber himself. I have 15+ years practical experience on a wide variety of teams. The biggest unlock to productivity I’ve found is eliminating practices associated with estimations, or what I call “the guessing game”.
If you’re not building the right thing, it doesn’t matter when it’s done. I don’t care about the iPhone you built me if my house is on fire.
If you do know you’re working on the right thing (prioritization) then it equally doesn’t matter when it will be done. I don’t ask the firemen to sit down and estimate time on each of their tasks to get to my house and put out the fire, please skip that step and just get here.
Finally, if you’re not sure the thing you’re building is the right thing or not, it’s time to shift focus to figuring it out as quickly as possible. Here the “figure it out” becomes the priority.
In each of these cases we can shift focus from timing to priority.
This assumes you have a competent working engineering team focused on fast feedback, high quality, and high speed. But it’s a bit of chicken and egg situation. You may not have a good eng team because they are experiencing the friction brought about by estimations.
The job of a product delivery team is to try as many variations as quickly as possible to discover the best. The job of a software engineer on a product team is to build high quality code fast. None of these require estimating tickets, building gantt charts, or sequencing timelines.
By spending time on estimates, sprint capacity, and project timelines, we shift the focus from solving customer problems to “the guessing game”: carefully guessing how long things take and striving to hit those commitments.
But what about—
Our stakeholders are making commitments to customers and we need to hit those timelines
In certain niche situations this may be true, if so I’d push towards a “Sprint” (the book) style of work where time is the only thing that matters.
For 99% of teams there are two cases:
- We can “bubble up” the sentiment that the business focuses on priority not timelines and we can share our prioritized list with customers.
- We can pull timelines out of thin air. The research shows this is equally accurate as our best guess timelines. Product and stakeholders can look at the number of tickets and how many are done vs left and play their own guessing game if they want, no need to get engineers involved.
The issue here is that in most teams the org is too afraid to even try. What happens when they do is they see their previously projected timelines become a joke. With the speedup engineers get from cutting pointing ceremonies, product delivery gets so fast that the business can’t keep up. “When” a project is delivered doesn’t matter when its so fast. Product starts collecting new features and padding out release times to optimize the marketing side.
Our lazy engineers will never get their job done without time pressure
If you’re evaluating engineers on “the guessing game” you’ve already lost. You will have high turnover, mediocre product, and constantly accumulating code debt. Great engineering teams build high quality product fast. Part of why they do so is that they cut out any activities that do not support high quality code made fast. Pointing tickets is an early offender to be cut. It adds friction and distraction and takes time and attention away from what matters for engineering and product delivery.
Our eng team has great conversations around pointing that we would miss
This is a great realization! How do you get those conversations without pointing? What you’ll quickly realize is that pointing is a crutch here. The meaningful conversation that happens after pointing is actually where the conversation should start, you can skip everything before then and just jump into meaningful conversation. It take some practice but saves 50% of many meeting times when you get there.