I just hope that Maarten didn't really meet a person in the Scrum Master responsibility who focused on this creepy Excel spreadsheet during Sprint Planning. If he did, then I would very much like to question the Scrum Master's understanding :)
There is opportunity to apply philosophy for sure, particularly understanding and shortening feedback loops and iteration on design, from one prototype to the next and sometimes in parallel.
But estimation is a guessing gam that must be played.
I agree with all of this, but starting to question the futility when I started working with hardware, where early detection of missing a manufacturing deadline can save sooo much money. Indicators that can give insight to delays 6 weeks earlier are worth the wasted effort for those that don't pan out.
This is simply a lot of words to say "we're a kanban team pretending to do sprints". Sure you have a sprint goal but if there's no consequence for not meeting this goal, then why write a goal in the first place?
The reason agile came into existence is to help development teams break down complex problems and deliver iterative bits of features. You absolutely don't need to perfect your ability to predict the future based on capacity, but you DO need to have some level of confidence on your ability to deliver within a certain timeframe.
Breaking your ideas into clearly defined tickets and clearly stating the definition of done goes a long way in being able to say at the start of a sprint "this is what we've set out to do and the team agrees we can accomplish this in X weeks". During retro, you look back at what went wrong if you didn't meet that goal and take those learnings into the next sprint.
After you do this many times (6+ months), the team will start to form a natural progression of having much higher confidence in their ability to predict future delivery dates. This builds trust with other teams and leadership at your company because development isn't this blackhole of hopes and dreams.
You're committing to the Sprint Goal, that doesn't mean there is no consequence - who said that?
Kanban and Scrum are compatible with each other, hence there also is the Kanban Guide for Scrum Teams - the only difference is setting a goal and pulling in work based on that.
The level of confidence you need, doesn't have to come from estimating, or haven doing any fancy Monte Carlo forecasting or whatever. All you need is a group of people who say that they think they can complete something during the Sprint (see Capacity-Driven Planning by Mike Cohn) - https://www.mountaingoatsoftware.com/blog/capacity-driven-sprint-planning
Much higher confidence, still isn't a guarantee, it can still slip in a crazy way because shit happens :). Been there and got the t-shirt.
I found the article a bit confusing. We CAN predict the future when we have known quantities, i.e. Holidays, vacations, company meetings. These are not guesses and they take away from time in the sprint. The article then goes on to talk about velocity as a planning tool, which I completely agree with. But, then it proposes a team estimated 600 hours of work for those 40 story points...and agreed to that amount of work? As stated, as we get closer to implementation we typically know more. And, since those 40 story points were done in the past during refinement I'd trust the estimating done TODAY in Sprint Planning, which means we can't possibly take on 600 hours. So, plan for less work. From experience, pulling in work "as-needed" can be disastrous because almost every developer I've worked with uses the available time to polish and perfect. So, the risk is that the first task, when implemented to perfection, will take the entire iteration. It's the gas law. We use as much space as given. I'd much rather select the appropriate amount of work, leave it all unassigned and have developers take on new Tasks throughout the sprint. Just the simple visual of the amount of work is a reminder that it doesn't need to be perfect, we have multiple opportunities for feedback and it's important we get as much as possible in front of users and stakeholders.
Thanks for your comment, first of all, I understand it's confusing, let me clarify.
1) Yes, it does take away time to do work, but since you're not pushing in work based on a capacity you've guessed, it doesn't really matter. You pull in work as real capacity becomes available.
2) Double estimation is a well-documented anti-pattern, you're correct, if you were to estimate those 40 Story Points in hours and break down in sub-tasks, then you'd discover it, but you shouldn't be doing it, as it slows you down. See https://www.projectmanagement.com/pdf/469163_the-impact-of-agile-quantified.pdf
The point which may be confusing (I will see if I can clarify), those 40 Story Points represent 600 hours but you DON'T know it (that's why you're using Story Points.
3) You're correct, developers will use the time to polish and perfect, but that's why you still have a constraint: the Sprint Goal, plus the Sprint duration (you're pulling in work that you have reasonable confidence that it fits in the Sprint). And, because you know the estimates, it takes too long, you can still talk about it and inspect and adapt.
For What It's Worth: It's all a balancing act about quality vs. speed etc. As Maarten states: the Sprint Goal and duration will provide those additional constraints and help adapt to what is the 'right thing to do'. Sometimes, polishing and perfecting, is important (e.g. refactoring). As a Developer, how do we know what we commit/merge today is going to stand the tests of time or even scale? Flow Distribution metrics are good to use as a leading indicator when planning. The Sprint name is not meant to be literal; sprinting is only possible with lots of rest in between metaphorically and literally.
"Adapt to reality at a time when you have the best information at your disposal about your situation" This!
I really liked the line - Instead of pushing in work based on capacity, pull in work based on the flow of work. !!
I just hope that Maarten didn't really meet a person in the Scrum Master responsibility who focused on this creepy Excel spreadsheet during Sprint Planning. If he did, then I would very much like to question the Scrum Master's understanding :)
There is opportunity to apply philosophy for sure, particularly understanding and shortening feedback loops and iteration on design, from one prototype to the next and sometimes in parallel.
But estimation is a guessing gam that must be played.
I agree with all of this, but starting to question the futility when I started working with hardware, where early detection of missing a manufacturing deadline can save sooo much money. Indicators that can give insight to delays 6 weeks earlier are worth the wasted effort for those that don't pan out.
We are lucky in software, to have flexible scope and deployments that are not so bound to physical constraints.
I never worked in hardware, so that's a whole different world I can't fully take into consideration. Maybe one day! :)
This is simply a lot of words to say "we're a kanban team pretending to do sprints". Sure you have a sprint goal but if there's no consequence for not meeting this goal, then why write a goal in the first place?
The reason agile came into existence is to help development teams break down complex problems and deliver iterative bits of features. You absolutely don't need to perfect your ability to predict the future based on capacity, but you DO need to have some level of confidence on your ability to deliver within a certain timeframe.
Breaking your ideas into clearly defined tickets and clearly stating the definition of done goes a long way in being able to say at the start of a sprint "this is what we've set out to do and the team agrees we can accomplish this in X weeks". During retro, you look back at what went wrong if you didn't meet that goal and take those learnings into the next sprint.
After you do this many times (6+ months), the team will start to form a natural progression of having much higher confidence in their ability to predict future delivery dates. This builds trust with other teams and leadership at your company because development isn't this blackhole of hopes and dreams.
You're committing to the Sprint Goal, that doesn't mean there is no consequence - who said that?
Kanban and Scrum are compatible with each other, hence there also is the Kanban Guide for Scrum Teams - the only difference is setting a goal and pulling in work based on that.
The level of confidence you need, doesn't have to come from estimating, or haven doing any fancy Monte Carlo forecasting or whatever. All you need is a group of people who say that they think they can complete something during the Sprint (see Capacity-Driven Planning by Mike Cohn) - https://www.mountaingoatsoftware.com/blog/capacity-driven-sprint-planning
Much higher confidence, still isn't a guarantee, it can still slip in a crazy way because shit happens :). Been there and got the t-shirt.
This is a hybrid Sprint/Kanban approach
I found the article a bit confusing. We CAN predict the future when we have known quantities, i.e. Holidays, vacations, company meetings. These are not guesses and they take away from time in the sprint. The article then goes on to talk about velocity as a planning tool, which I completely agree with. But, then it proposes a team estimated 600 hours of work for those 40 story points...and agreed to that amount of work? As stated, as we get closer to implementation we typically know more. And, since those 40 story points were done in the past during refinement I'd trust the estimating done TODAY in Sprint Planning, which means we can't possibly take on 600 hours. So, plan for less work. From experience, pulling in work "as-needed" can be disastrous because almost every developer I've worked with uses the available time to polish and perfect. So, the risk is that the first task, when implemented to perfection, will take the entire iteration. It's the gas law. We use as much space as given. I'd much rather select the appropriate amount of work, leave it all unassigned and have developers take on new Tasks throughout the sprint. Just the simple visual of the amount of work is a reminder that it doesn't need to be perfect, we have multiple opportunities for feedback and it's important we get as much as possible in front of users and stakeholders.
Thanks for your comment, first of all, I understand it's confusing, let me clarify.
1) Yes, it does take away time to do work, but since you're not pushing in work based on a capacity you've guessed, it doesn't really matter. You pull in work as real capacity becomes available.
2) Double estimation is a well-documented anti-pattern, you're correct, if you were to estimate those 40 Story Points in hours and break down in sub-tasks, then you'd discover it, but you shouldn't be doing it, as it slows you down. See https://www.projectmanagement.com/pdf/469163_the-impact-of-agile-quantified.pdf
The point which may be confusing (I will see if I can clarify), those 40 Story Points represent 600 hours but you DON'T know it (that's why you're using Story Points.
3) You're correct, developers will use the time to polish and perfect, but that's why you still have a constraint: the Sprint Goal, plus the Sprint duration (you're pulling in work that you have reasonable confidence that it fits in the Sprint). And, because you know the estimates, it takes too long, you can still talk about it and inspect and adapt.
Thanks once again!
Neat reference to the Impact of Agile Quantified. I used to work on that. :)
For What It's Worth: It's all a balancing act about quality vs. speed etc. As Maarten states: the Sprint Goal and duration will provide those additional constraints and help adapt to what is the 'right thing to do'. Sometimes, polishing and perfecting, is important (e.g. refactoring). As a Developer, how do we know what we commit/merge today is going to stand the tests of time or even scale? Flow Distribution metrics are good to use as a leading indicator when planning. The Sprint name is not meant to be literal; sprinting is only possible with lots of rest in between metaphorically and literally.