Comments on: What’s with all the Agile Process Overhead? Part 1 http://www.rallydev.com/agileblog/2009/02/whats-with-all-the-agile-process-overhead-part-1/ Adopt, Scale and Succeed with Agile Development Tue, 10 Jan 2012 03:30:50 +0000 hourly 1 http://wordpress.org/?v=3.0.5 By: Jean Tabaka http://www.rallydev.com/agileblog/2009/02/whats-with-all-the-agile-process-overhead-part-1/#comment-222 Jean Tabaka Tue, 03 Mar 2009 01:40:31 +0000 http://www.rallydev.com/agileblog/?p=639#comment-222 Ravi, You look as though you and your team have a sound process for continually improving how you allocate your work in a Sprint. In my next post, you will see that I refer to your comment. I stress the need to think about ideal effort hours and then even add on a buffer for unknowns on top of that. Thank you for your feedback! Jean Ravi, You look as though you and your team have a sound process for continually improving how you allocate your work in a Sprint. In my next post, you will see that I refer to your comment. I stress the need to think about ideal effort hours and then even add on a buffer for unknowns on top of that. Thank you for your feedback! Jean

]]> By: Ravi Jha http://www.rallydev.com/agileblog/2009/02/whats-with-all-the-agile-process-overhead-part-1/#comment-187 Ravi Jha Fri, 27 Feb 2009 21:00:26 +0000 http://www.rallydev.com/agileblog/?p=639#comment-187 Hi, We use Rally for our Scrum and found it good. When we started Scum and started using rally for it we also started putting everything in sprint backlog and found it is not good. So we did following 1. We removed everything from Sprint backlog not it was decided not to use Rally as time sheet tool, for that you have other tools which you use for time sheet. 2. We looked into our history and found no one can work for 8 hrs so we decided to barin storm and find out what is the time members actually work on development keeping aside meetings, emails and other stuffs. We found it is actually 6 hrs which productive and 2 hrs goes into discussion, meeting, issues , emails and other stuffs 3. We use another tool, Change Point, for request tracking from customer which has epic stories. We do have initial estimates for those epic stories 4. In the “Change Point” we decide which story goes in what release, so we do our release plan with this tool 5. Once we know our release then we start importing stories for the current and next release into rally. 6. In rally now we have stories for next release in the sprint backlog and stories for current release are in release backlog. 7. In release back log we start breaking up the epic stories into smaller stories. 8. Now Product owner rank these stories in release backlog ( he also ranks the stories in sprint backlog but that is very high level fron 20000 ft) 9. In iteration planning team members start breaking the stories available in release backlog into smaller stories and tasks. 10. once we finish that we start estimating tasks and team members start taking responsibility for the tasks, 11. Here we start keeping track of each story estimate and team members assigned tasks estimates. 12. we keep comparing the estimates with the previously calculated velocity for the team and each team so that we should not over commit or over allocated 13. We plan for iteration only for 85 % of its capacity keeping 15% for support. 14. Before we goes into iteration Scrum Master do calculate each team members availability for that iteration considering Vacation and other stuffs 15. Once we reach upto 85% of capacity we move those stories in Iteration and commit 16. Stories left in release backlog will be considered in next iteration plan Here you may say 1st we have cut productive hrs and considered only 6 hrs out of 8 hrs and then plan for 85% of the capacity. Yes that’s valid but we actually compared the output and cost and found we have saved 3000Hrs @ $100/member = 300000. This we could achieved only because team was so committed to its commitments and free to take any task and doing other tasks like testing, reviewing documentation. Hi,

We use Rally for our Scrum and found it good. When we started Scum and started using rally for it we also started putting everything in sprint backlog and found it is not good. So we did following

1. We removed everything from Sprint backlog not it was decided not to use Rally as time sheet tool, for that you have other tools which you use for time sheet.
2. We looked into our history and found no one can work for 8 hrs so we decided to barin storm and find out what is the time members actually work on development keeping aside meetings, emails and other stuffs. We found it is actually 6 hrs which productive and 2 hrs goes into discussion, meeting, issues , emails and other stuffs
3. We use another tool, Change Point, for request tracking from customer which has epic stories. We do have initial estimates for those epic stories
4. In the “Change Point” we decide which story goes in what release, so we do our release plan with this tool
5. Once we know our release then we start importing stories for the current and next release into rally.
6. In rally now we have stories for next release in the sprint backlog and stories for current release are in release backlog.
7. In release back log we start breaking up the epic stories into smaller stories.
8. Now Product owner rank these stories in release backlog ( he also ranks the stories in sprint backlog but that is very high level fron 20000 ft)
9. In iteration planning team members start breaking the stories available in release backlog into smaller stories and tasks.
10. once we finish that we start estimating tasks and team members start taking responsibility for the tasks,
11. Here we start keeping track of each story estimate and team members assigned tasks estimates.
12. we keep comparing the estimates with the previously calculated velocity for the team and each team so that we should not over commit or over allocated
13. We plan for iteration only for 85 % of its capacity keeping 15% for support.
14. Before we goes into iteration Scrum Master do calculate each team members availability for that iteration considering Vacation and other stuffs
15. Once we reach upto 85% of capacity we move those stories in Iteration and commit
16. Stories left in release backlog will be considered in next iteration plan

Here you may say 1st we have cut productive hrs and considered only 6 hrs out of 8 hrs and then plan for 85% of the capacity. Yes that’s valid but we actually compared the output and cost and found we have saved 3000Hrs @ $100/member = 300000.

This we could achieved only because team was so committed to its commitments and free to take any task and doing other tasks like testing, reviewing documentation.

]]>