(This is an update to my 10/28/12 post on How to Avoid Overcommitment During Sprint Planning. )
For awhile now I have been using an excel spreadsheet I put together to work out the calculations I detailed in the post on avoiding overcommitment. I have also been sharing it with the students in my CSM classes. I recently updated it so that the times allocated for the different Scrum meetings is in sync with the current version of the Scrum Guide and I thought it would be a good idea to post here just in case it can be of help to anyone.
In case you missed the earlier post, the intention of this calculator is to help individual team members on a Scrum Team gain a better (more true) understanding of the amount of time the can realistically commit/forecast to be able to contribute to the work the team will do during a Sprint. I have found this to be very helpful for teams who are struggling with understanding their capacity.
An example of how this could be used in s Sprint Planning is...
1. Once a Scrum Team has forecasted the amount of Story Points it can expect to get through during a given Sprint based on average historical velocity.
2. And defined tasks for all the stories.
3. And estimated the ideal engineering hours required to complete each individual task.
4. And totalled up the collective ideal engineering hours required to complete all the work they are forecasting to complete in the Sprint.
5. Each team member can use this calculator to determine how much time he/she can expect to be able to contribute in the Sprint.
6. Once each team member has come up with his/her number, you would total those up to get the total amount of ideal engineering hours the Team expects to be able to working during the Sprint.
7. If the value resulting from Step 4 is greater than the value from Step 6, then you may need to reconsider the amount of work your team is forecasting to complete in the Sprint, or modify the scope (and tasks) for one of the stories.
8. If the value resulting from Step 4 is significantly less than the value resulting from Step 6, you may need to consider adding some additional stories/work into what is being forecasted for the Sprint.
* Some teams I have worked with have taken the additional step of applying this technique by work type within a Sprint, i.e. Development, QA, UX, etc.
Here is the file
.
For awhile now I have been using an excel spreadsheet I put together to work out the calculations I detailed in the post on avoiding overcommitment. I have also been sharing it with the students in my CSM classes. I recently updated it so that the times allocated for the different Scrum meetings is in sync with the current version of the Scrum Guide and I thought it would be a good idea to post here just in case it can be of help to anyone.
In case you missed the earlier post, the intention of this calculator is to help individual team members on a Scrum Team gain a better (more true) understanding of the amount of time the can realistically commit/forecast to be able to contribute to the work the team will do during a Sprint. I have found this to be very helpful for teams who are struggling with understanding their capacity.
An example of how this could be used in s Sprint Planning is...
1. Once a Scrum Team has forecasted the amount of Story Points it can expect to get through during a given Sprint based on average historical velocity.
2. And defined tasks for all the stories.
3. And estimated the ideal engineering hours required to complete each individual task.
4. And totalled up the collective ideal engineering hours required to complete all the work they are forecasting to complete in the Sprint.
5. Each team member can use this calculator to determine how much time he/she can expect to be able to contribute in the Sprint.
6. Once each team member has come up with his/her number, you would total those up to get the total amount of ideal engineering hours the Team expects to be able to working during the Sprint.
7. If the value resulting from Step 4 is greater than the value from Step 6, then you may need to reconsider the amount of work your team is forecasting to complete in the Sprint, or modify the scope (and tasks) for one of the stories.
8. If the value resulting from Step 4 is significantly less than the value resulting from Step 6, you may need to consider adding some additional stories/work into what is being forecasted for the Sprint.
* Some teams I have worked with have taken the additional step of applying this technique by work type within a Sprint, i.e. Development, QA, UX, etc.
Here is the file
(Link updated July 2019)
This work is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License
.
No comments:
Post a Comment