Mike you are great! Love all of your videos! Here is a timeline for getting around more easily: 10:34 - A team with historical data 18:46 - Fixed-date plans and Fixed-scope plans 42:33 - A team with no velocity data 31:06 - A team changing size
Thanks Mike, Based on the advice my coach, I went through your videos and feel that my "PRACTICAL" understanding of the SCRUM increased or say much evolved than before. I am making this useful for my career !
if we do not get the contract then how can boss will be happy in long term ? is scrums really fit for all the various business model of the different companies.
No, I don't think Scrum is necessarily a fit for all business models. But I very successfully ran my company doing outsourced contract development projects for others, often on fixed-date, fixed-scope basis. If you don't get the contract, you're right, a boss probably will not be happy. But perhaps the boss should be. Suppose you bid 500 hours on a project because you think it will take 400-600 hours and you go right in the middle. The client says no. Boss is disappointed, which is different than unhappy. Now suppose the client says, "500 is too high but we'll go with you if you promise 400." Your estimate was 400-600. So perhaps there is a 1 out of 200 chance you can finish in 400. Would the boss really take that bet? Woudl anyone really be happy with that risk-reward ratio? Sometimes the right answer is to walk away from projects. Deep down, bosses know that. They can still be disappointed that a client had unrealistic expectations and we lost the work, though.
@@MountainGoatSoftware Thank you Mike I watch your videos and blogs. 6ou already explain in video. But problem is owner should have that much maturity. Values begin at Top so as Scrum Otherwise it will cascade down to Scrum team.
Great video Mike! Very interesting stuff. One question though: For the team which has no velocity, we can estimate with hours and add the story points to get the team velocity but how do we get the story points for the backlog if the team is new?
fun side thought: the number of iterations to throw out from each end as part of calculating a confidence interval has parallels with how many scores to throw out when calculating a golf handicap :-)
Mike, the approach you suggest in planning time/scope requires the project to be well defined and clear, at least knowing all the user stories and tasks, and their estimates. Wouldn't such a Big design upfront go against agile principles?
Ok, I just wanted to make sure it is indeed a tradeoff, and generally not something to strive for, but a compromise. Thank you for the reply and for the videos, good content.
***** When you say "win the contract", what exactly is the deliverable you're agreeing to? A sprint? release? By definition we have variable scope in agile, so how do you determine objectives and measures for success?
Thanks a lot for knowledge you shared. Great thanks GURUJI. I have a question. Story points vs Man hours. Is it not better to calculate velocity in man hours instead of story points. Is it not hard to convince people {clients} on story points, I cant say to client who is having no knowledge in story points and who understands in man hours and love to listen "THis story completes in .. hours" . How do we calculate story points from user stories what criteria or rules we must follow. Thanks in Advance.
Mike you are great! Love all of your videos!
Here is a timeline for getting around more easily:
10:34 - A team with historical data
18:46 - Fixed-date plans and Fixed-scope plans
42:33 - A team with no velocity data
31:06 - A team changing size
Team changing size : 51:06 you mean
Thanks Mike, Based on the advice my coach, I went through your videos and feel that my "PRACTICAL" understanding of the SCRUM increased or say much evolved than before. I am making this useful for my career !
The birthday example was great :-)
Thanks.
Thanks Mike. At 50:15, you reversed the %- 119% should give you the upper range, 13, and 81% should give you the lower range, 9.
if we do not get the contract then how can boss will be happy in long term ? is scrums really fit for all the various business model of the different companies.
No, I don't think Scrum is necessarily a fit for all business models. But I very successfully ran my company doing outsourced contract development projects for others, often on fixed-date, fixed-scope basis.
If you don't get the contract, you're right, a boss probably will not be happy. But perhaps the boss should be. Suppose you bid 500 hours on a project because you think it will take 400-600 hours and you go right in the middle. The client says no. Boss is disappointed, which is different than unhappy. Now suppose the client says, "500 is too high but we'll go with you if you promise 400." Your estimate was 400-600. So perhaps there is a 1 out of 200 chance you can finish in 400. Would the boss really take that bet? Woudl anyone really be happy with that risk-reward ratio? Sometimes the right answer is to walk away from projects. Deep down, bosses know that. They can still be disappointed that a client had unrealistic expectations and we lost the work, though.
@@MountainGoatSoftware Thank you Mike I watch your videos and blogs. 6ou already explain in video. But problem is owner should have that much maturity. Values begin at Top so as Scrum Otherwise it will cascade down to Scrum team.
Great video Mike! Very interesting stuff. One question though: For the team which has no velocity, we can estimate with hours and add the story points to get the team velocity but how do we get the story points for the backlog if the team is new?
Great video! Very helpful to review all the different scenario where you may need to plan.
fun side thought: the number of iterations to throw out from each end as part of calculating a confidence interval has parallels with how many scores to throw out when calculating a golf handicap :-)
Mike, the approach you suggest in planning time/scope requires the project to be well defined and clear, at least knowing all the user stories and tasks, and their estimates. Wouldn't such a Big design upfront go against agile principles?
Ok, I just wanted to make sure it is indeed a tradeoff, and generally not something to strive for, but a compromise. Thank you for the reply and for the videos, good content.
Mike amazing video. Extremely helpful. Thank you so much.
Do team size change after Sprint 1 Starts ?
The team size can change at any time, but there is no planned change after one sprint.
***** When you say "win the contract", what exactly is the deliverable you're agreeing to? A sprint? release? By definition we have variable scope in agile, so how do you determine objectives and measures for success?
***** Thanks very much, Mike.
Superb stuff mike...
Thanks a lot for knowledge you shared. Great thanks GURUJI.
I have a question.
Story points vs Man hours. Is it not better to calculate velocity in man hours instead of story points. Is it not hard to convince people {clients} on story points, I cant say to client who is having no knowledge in story points and who understands in man hours and love to listen "THis story completes in .. hours" . How do we calculate story points from user stories what criteria or rules we must follow.
Thanks in Advance.
***** Thanks Cohn. Sure will have a look in to it.
Mike, Thank you again!
Thanks for helpful info
thanks sir
What are the chances that engineers are going to puke all over this and object to being evaluated by such strict methods? Really, I ask you seriously?
@@MountainGoatSoftware Hmm, ok. As long as it's not being used as a club by management which most seasoned engineers I've worked with will take it as.