In my earlier blog, I explained how we should do commitment driven planning. I thought it would be good idea to share why I prefer Commitment Driven Planning.
I would suggest if you don't have experience then try them both yourself. I have my preference toward Commitment Driven Planning.
The biggest issue I face with velocity driven planning, is being predictable. Velocity is volatile. It moves around from iteration to iteration. It bounces around. Again it lot depends upon what your team is doing? Are they developing as well as supporting software which is under constant change. Because incase of less challenging environment you might be able to predict them but in average team environment it is very taxing job.
If I have to take average of my team's last 6 iteration velocity which ranges from 26 to 90 story points. The average is around 35 story points but can we plan 7th iteration with 35 points, is this right amount of work? I tried scheduling work based on our average and failed. I tried doing and taking same approach for next three iteration and failed..
I could not predict the number of story points my team might deliver. Simply because there were lots of unplanned work keeping coming along our way and also team did not think about technical design that well in advance and we failed for numerous other reasons.
Velocity depends upon lots of factor and I think it's variability create more issues vs. helping us. I would love to let my team work at their best potential without thinking about the velocity. Velocity is valuable over long term i.e like building customer profile may take 8 sprints on an average. My team is producing at 35 story points on average but that does not mean they have to product 35 story points every sprint. Over the period of 10 sprint they will produce on average of 350 story points but bringing this much work on each sprint based on this average would not work.
We should always remember the purpose of sprint planning. The purpose of sprint planning is to commit to a set of product backlog items. The purpose is not to come up with the list of task or hours but tasks and estimates are a tools for determining what we can commit to.
As usual let me know your feedback or if are doing it differently in your team.
Thanks
Manisha
I would suggest if you don't have experience then try them both yourself. I have my preference toward Commitment Driven Planning.
The biggest issue I face with velocity driven planning, is being predictable. Velocity is volatile. It moves around from iteration to iteration. It bounces around. Again it lot depends upon what your team is doing? Are they developing as well as supporting software which is under constant change. Because incase of less challenging environment you might be able to predict them but in average team environment it is very taxing job.
If I have to take average of my team's last 6 iteration velocity which ranges from 26 to 90 story points. The average is around 35 story points but can we plan 7th iteration with 35 points, is this right amount of work? I tried scheduling work based on our average and failed. I tried doing and taking same approach for next three iteration and failed..
I could not predict the number of story points my team might deliver. Simply because there were lots of unplanned work keeping coming along our way and also team did not think about technical design that well in advance and we failed for numerous other reasons.
Velocity depends upon lots of factor and I think it's variability create more issues vs. helping us. I would love to let my team work at their best potential without thinking about the velocity. Velocity is valuable over long term i.e like building customer profile may take 8 sprints on an average. My team is producing at 35 story points on average but that does not mean they have to product 35 story points every sprint. Over the period of 10 sprint they will produce on average of 350 story points but bringing this much work on each sprint based on this average would not work.
We should always remember the purpose of sprint planning. The purpose of sprint planning is to commit to a set of product backlog items. The purpose is not to come up with the list of task or hours but tasks and estimates are a tools for determining what we can commit to.
As usual let me know your feedback or if are doing it differently in your team.
Thanks
Manisha
No comments:
Post a Comment