Auf YouTube findest du die angesagtesten Videos und Tracks. Außerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.
Sprints aren’t for you, it’s for the higher ups to have a digestible view of what’s going on in the team by presenting work done over 2-3 weeks, calibrating budgets, etc.
As a dev, yeah, sprints feel restrictive and artificial as fuck lol
If you still do the sizing (it’s not entirely wasted as it’s a reasonably effective tool to gauge understanding across the team), This can still be done without the artificial time boxing.
“How much work have we done in the last two weeks?” Just look at all the stories closed in the last two weeks. Easy.
“When will X be delivered?” Look at X and all its dependencies, add up all the points, and guesstimate the time equivalence.
Kanban isn’t a free for all, you still need structure and some planning. But you take most of that away from the do-ers and let them do what they do best… do.
I prefer V-cycle for when you have a software with known specs & Kanban for when you don’t really know what the client needs/wants. I mean those magic clients you hear about but never sees…
And the only thing even worse than SCRUM is literally every other option
And I think this video is talking about scrum implemented poorly. But admittedly that’s the only way I’ve seen it done 😐
I’m able to get the good parts of scrum without all the overhead with kanban. Sprints are worthless, work doesn’t align on a 2 week cadence anyway.
Sprints aren’t for you, it’s for the higher ups to have a digestible view of what’s going on in the team by presenting work done over 2-3 weeks, calibrating budgets, etc.
As a dev, yeah, sprints feel restrictive and artificial as fuck lol
If you still do the sizing (it’s not entirely wasted as it’s a reasonably effective tool to gauge understanding across the team), This can still be done without the artificial time boxing.
“How much work have we done in the last two weeks?” Just look at all the stories closed in the last two weeks. Easy.
“When will X be delivered?” Look at X and all its dependencies, add up all the points, and guesstimate the time equivalence.
Kanban isn’t a free for all, you still need structure and some planning. But you take most of that away from the do-ers and let them do what they do best… do.
I prefer V-cycle for when you have a software with known specs & Kanban for when you don’t really know what the client needs/wants. I mean those magic clients you hear about but never sees…