Today’s post will be short as I’m preparing a presentation for an upcoming Tech Excellence meetup.
Let’s face it, your user stories are too fat
A surprising observation that I struggled very much to understand is that despite not being able to estimate accurately, sprints fit neatly into weekly increments with most teams I worked with.
It turns out it’s really easy to plan something and say it’s going to be done next week / month.
Daily is hard, hourly is harder
The challenge comes from being brutally honest and simply accepting that every step will be difficult. Have a feature touching 8 files and a config?
Try to deploy each one separately.
Plan your work so that you can do so. Plan your team’s collaboration times so it happens smoothly. You may laugh, but this is what hyper-productive teams are best at that most of us struggle with.
The Smallest Unit of Planning Will Align to your Smallest Definition of a Story or Feature.
Your Stories determine your estimates, not your estimates
If your stories take a week on average from first-contact-to-commit-to-release, then the best estimate you can do is about 2 weeks +/- 3 days. If your user stories are a few days on average, the best you can do is a sprint +/- 1 day.
Only when your stories take less than a few hours can you reasonable estimate deliverables and releases to an exact day on the calendar.
It is unintuitive — you may think that releasing that often will slow you down. The reality is that with continuous delivery automation this slowdown is barely noticable.
What’s noticeable however, is the immediate feedback you get if you are going the wrong direction or prioritising the wrong efforts.
I call this methodology Tactical Agility — the process of continually asking yourself “what can we deploy today” and “how can we deploy the 5% that’s done and works”
Most Teams Abuse sprints as a Habitual Pattern to Structure Their Meetings
Try a 2.5day Sprint
A clever psychological trick out of this is to plan your sprints for 2 days and a half. This will get your team out of dismissing releasing that are far in the future and have them incorporate it into their daily activities for every single task they are personally responsible for.
Most Teams Abuse sprints as a Habitual Pattern to Structure Their Meetings. Weekly this, daily that, monthly other. Bla bla bla. Process Cruft! The sprint is done when the goal is achieved. Which means ideally way before the deadline. Not that I advocate sprints, but if you do use them try to cancel some and make them shorter. Aim for a cadence that doesn’t naturally align with a week or month.
Get out of your comfort zone, stop spamming your team with ad infinitum recurring meetings for “planning”.
"Most Teams Abuse sprints as a Habitual Pattern to Structure Their Meetings." - Love that description! Hate that it's true!