2-week sprints or 3-week sprints. Which one will fail?
Agile does't mean quick, right? It means to simply be able to focus on a few things without distraction. And pivot as needed to deliver the best product or feature possible.
In this episode, I share my thoughts on when its appropriate to use 3-week sprints vs 2-week sprints. And which one will lead to success without pushing you and your team into a risky area.
Over the past decade, I've helped dozens of companies better understand Adobe technology and project delivery. Along the way I've had the opportunity to see a lot of what works and a lot of what doesn't. My goal is simply to share with YOU what I've learned. And I hope that gives you back a little sanity in your day.
💡 What do you think? Share your thoughts in the comments and let's have a conversation about it.
________________________________________________________________________________________________
Transcript:
So. Agile doesn't mean quick, right? It means just simply to be able to focus on a few things without distraction. And pivot as needed to deliver the best product or feature possible.
Two weeks sprints. So two weeks sprints, you have 10 days to actually get work done. And in that time you need to have a handful of meetings. You need to figure out who does what. Code test deploy, retest refactor, write unit, test deploy, and hopefully demo on time. Hopefully demo on time.
And of course there are status updates. You have to give daily, if not hourly.
If you're a small agile team, say two or three developers and you're updating small features or maybe fixing some bugs, then yeah. Two weeks sprints make sense.
But when you have a larger project to complete meaning you're doing a large implementation. Or you simply just have a huge backlog of things you need to get done. That's where three weeks sprints really should fit the bill a little bit better, right? Because it gives you a little bit more breathing room to focus on building the right solution.
It gives you some time to actually structure some process into your code. Ask questions. Interact with the business and collaborate to see what requirements and may have been missing or clarification seemed to happen on those requirements. And also gives QA enough time to do some iterative feedback, making sure that the developers know kind of what's working, what's not working.
And one of the goals of having a three week sprint right, or 15 business days is you can get demos, actually deployed to the environments where they should be working on. Right. No more local demos.
My thinking is.
If you have a two week sprint and you're focusing on doing large implementation type work, you're kind of pushing yourself into a risky area.
What do you think. Give me some information in the comments and let's have a conversation about it