I guess I fundamentally reject the idea that a team should be able to plan and estimate weeks worth of work and if everything doesn’t go according to plan, then you did something wrong and need to figure out how to do better next time.
And you wouldn’t even disagree with scrum here. Whoever taught that, misinterpreted the scrum guide. You don’t need to figure everything out. See scrum as an instrument that shows you a result, nothing more. You as a team interpret the result as you like. If you see no problem in the result, fine. Nothing to do, move on.
The way you say it sounds like someone put disappointment or bad energy into ‘failing’ a sprint.
The point of scrum is that you can not plan perfectly and expect funny results. A good SM might ask: “do you see this as a problem?” and let the team decide.
Scrum actually doesn’t even mind spill over or unfinished work, etc. At the end of the sprint we check out the outcome and then talk about the next opportunities. Half finished work is no problem and not even mentioned in the scrum guide. If there was disappointment or bad feelings about it, then some one among you did that on their own. As a team you can literally decide that you don’t mind spill over from sprint to sprint because you see no problem in it and move on without worry.
estimate weeks
In my opinion, time estimations are a distraction to everyone involved and never work. I’d recommend to estimate in complexities. To talk about them. Nothing else.
The problem is that committing to a fixed scope in a fixed timeframe with a fixed team size is always bad idea and Scrum makes an entire process out of this bad practice.
Again, misinterpretation. The sprint length is just for consistency, like planning meetings is easier that way. And measuring is easier too.
Scrum even allows you to renegotiate the scope dureing the sprint. It even says that in the scrum guide…
That’s fair, and having no consequences for unfinished work certainly takes the pressure off, though you’re correct that I’ve been on teams where there certainly were consequences for not getting done what you “committed to” for the sprint, which really made me resent the process. I’ve also been on teams where we happily moved unfinished work over each sprint, and it largely felt like we were just going through the motions. To your point, I suppose the latter is perfectly acceptable, though it felt wrong based on my previous experiences. In either case, I always wonder what the point is of time-boxing in the first place when you can just take it one backlog item at a time with Kanban while still engaging in the other useful practices.
And you wouldn’t even disagree with scrum here. Whoever taught that, misinterpreted the scrum guide. You don’t need to figure everything out. See scrum as an instrument that shows you a result, nothing more. You as a team interpret the result as you like. If you see no problem in the result, fine. Nothing to do, move on.
The way you say it sounds like someone put disappointment or bad energy into ‘failing’ a sprint. The point of scrum is that you can not plan perfectly and expect funny results. A good SM might ask: “do you see this as a problem?” and let the team decide.
Scrum actually doesn’t even mind spill over or unfinished work, etc. At the end of the sprint we check out the outcome and then talk about the next opportunities. Half finished work is no problem and not even mentioned in the scrum guide. If there was disappointment or bad feelings about it, then some one among you did that on their own. As a team you can literally decide that you don’t mind spill over from sprint to sprint because you see no problem in it and move on without worry.
In my opinion, time estimations are a distraction to everyone involved and never work. I’d recommend to estimate in complexities. To talk about them. Nothing else.
Again, misinterpretation. The sprint length is just for consistency, like planning meetings is easier that way. And measuring is easier too. Scrum even allows you to renegotiate the scope dureing the sprint. It even says that in the scrum guide…
That’s fair, and having no consequences for unfinished work certainly takes the pressure off, though you’re correct that I’ve been on teams where there certainly were consequences for not getting done what you “committed to” for the sprint, which really made me resent the process. I’ve also been on teams where we happily moved unfinished work over each sprint, and it largely felt like we were just going through the motions. To your point, I suppose the latter is perfectly acceptable, though it felt wrong based on my previous experiences. In either case, I always wonder what the point is of time-boxing in the first place when you can just take it one backlog item at a time with Kanban while still engaging in the other useful practices.