Capacity Planning - GASP

A GASP is a generally accepted Scrum Practice.

This is another issue where it's not wrong or right. It is a difference in approaches. I feel that a more mature scrum team does not need, and will not want to, plan by hours. I have coached teams to strive towards that. Teams forecast at the story level. We always have. (Well we used to commit!) We just use the hour estimates on tasks to verify that we are not thinking crazy. Over time we will just be able to eyeball if we can get things accomplished. I like the concept of doing it from the beginning. Pushing the team to maturity earlier than later is my suggested path.

Remember to take time and think about what value new methods provide. In this case, the team commits either way. No need to waste time with hour estimates. I suggest conservative commitments when they do this. Then a gradual push to see where they can get to. When they find their limits they will know their velocity. If they pull in more than they committed to, the customer team wins! The PO also wins in that the product team will be able to deliver a Release Plan really fast because there is not a great deal of time used in finding the velocity based on hours. If the PO does not deliver the Release Plan fast, then it is my experience that the Release Plan gets delivered to the PO.

Transient