I have a brand new team trying to develop a brand new application and frankly planning meetings are more like refinement meetings. We have those almost daily at this time but when we go into planning it’s like they are reading this PBI for the first time. I know we will get better as we go but it is painful. Thank you so much for sharing your wisdom. I appreciate every video. Cathey
@MountainGoatSoftware
Жыл бұрын
All good things take time. Don't forget to use your retrospectives to work together as a team to get better each sprint.
@MountainGoatSoftware
Жыл бұрын
Thanks for your kind words, Cathey. A fair number of teams spend way too much time in refinement. I coach teams to think of refinement as a "pre-planning checkpoint." The goal isn't to remove all uncertainty, it's just to make sure the team can most likely finish the item in the coming sprint even with some remaining open issues.
@rajeswarikv9396
3 ай бұрын
Excellent one.. Thank you so much
@MountainGoatSoftware
3 ай бұрын
You're welcome! Glad you like it!
@HelenG-s3d
Жыл бұрын
Once you've identified a Scrum team's average capacity, how much would you recommend reducing it by to allow for unexpected scope in a sprint? Really enjoying these videos Mike - so clear 😊😊
@MountainGoatSoftware
Жыл бұрын
Thanks, Helen. Thanks impossible to answer (but I'll try!). It really depends on the team, the nature of their work, the industry, the length of their sprints, and how well stakeholders do at not introducing changes. I'd say that it should be at least 10% of capacity for any team dealing with this issue at all. I've seen teams who are highly interrupt-driven need more than 50% but those teams are often help desk or similar teams who could benefit from Kanban instead. The key is to take a wild guess, try it and then adjust up or down. You'll never get it "right," but you can get it right on average. And try to set a high bar for what constitutes a worthwhile interruption.
@AFCAT-dk7po
Жыл бұрын
Suppose in one team there are 5 people and it's a two week Sprint. So the estimated hours should be around 300 hours. 5 resource * 10 days * 6 hours.
@MountainGoatSoftware
Жыл бұрын
Sounds reasonable but probably on the upper end of how much plannable time most teams get per day.
@math4341
4 ай бұрын
Once an active sprint begins and new information becomes available can the story be updated during the active sprint to reflect the LOE required to complete the story?
@MountainGoatSoftware
4 ай бұрын
I don't recommend revising the estimate. If you do you'll introduce more error into velocity calculations. This is because most items in your product backlog will have been estimated without any work done on them yet but a few items (such as this item) will have estimates that were revised mid-sprint. When you add up the points for each to determine velocity you're then adding apples and oranges--they're different. You're best just leaving the estimate alone. I will change the estimate in two situations: 1) You totally goof. You said it was 5 and it's 50. OK, you have to revise then. But don't do it on like 5 to 13. 2) You have learned you mis-estimated an entire set of stories. Perhaps stories that draw pie charts on the screen. If you've learned from this story that pie charts are harder to draw than estimated revise this story and other upcoming items still in the backlog. The key is that it it's a random whoops then you're really better off leaving it alone.
@softwareminimalist
Жыл бұрын
Agree with everything but the "hour estimates". List of tasks, yes. Hour estimates = micromanagement.
@MountainGoatSoftware
Жыл бұрын
I don't know any reason to equate a team estimating in hours for their own benefit with micromanagement. If a boss wants to micromanage, they'll do that without estimates or without even a sprint plan. Sure, some bosses will use anything tot micromanage but that is not a good reason to abandon a technique for all teams in the world.
@sadaf3710
Жыл бұрын
In my PoV hour estimates of tasks at the time of planning will give more clarity of tasks and will create timebox too. if team underestimates or overestimates it would be learning also for them. the hours are coming from team will give team feeling of ownership and commitment.
@MichaelBacarella
Жыл бұрын
We add hour estimates at the task level and I think it helps with capacity.
@MikeCohn
Жыл бұрын
@@MichaelBacarella Thanks for sharing. I’m not surprised-I see this all the time as well. Once a team figures it out with hours, I encourage them to try sprint planning without that level of detail and see if they can stay as good at planning.
@MountainGoatSoftware
Жыл бұрын
@@sadaf3710 Excellent points.
@MoeEl-x5t
Жыл бұрын
Hours ? Not story points ?
@MountainGoatSoftware
Жыл бұрын
A quick estimation of tasks in hours (or days) can be used as a sanity check that the sprint has been appropriately filled. You don't want to fill a 2 week sprint with one developer having 120 hours worth of tasks. You've overfilled the sprint in that case.
@MoeEl-x5t
Жыл бұрын
@@MountainGoatSoftware makes sense but we were chastised in the past for using hours and were directed to use our Velocity as a guide of how many "story points" we can fit into the Sprint
@MountainGoatSoftware
Жыл бұрын
@@MoeEl-x5t You should use your velocity to guide the team to fill the sprint (not quite all the way to account for unknown work) with stories. The quick hours check is just for the team. You don't even need to write it down. It should be a quick, minute long, conversation to verify that the sprint has been appropriately filled and that the team isn't over-reaching on the stories they've committed to.
Пікірлер: 21