Here is a second concern you might want to address: never allocate everyone’s hours completely. This is not just because of questions that they need to ask. It is because they can’t know exactly what complexities they may run into with the work they are signing up for. So, imagine that someone takes on an assignment that they estimate will take 10 hours. Then 5 more tasks that will take 5 hours each. That is now 10 + 25 total hours they of effort they are committing to in order to complete the work. To make sure that they have slack to take up any complexity or inaccuracy in their estimates, be careful about where you go from here. If the most truly productive hours anyone can have per day is 6 hours (a fairly standard number), look at what their total available hours for two weeks is: 6 * 10 = 60. If you allow slack for what they may not know about the work, say an additional hour per day, that is now 50 hours of work they can commit to. In this example, the team member has committed to 35 hours of work. Until they can prove that they are very good at calculating complexity and estimating the work to complete it, they should not take on more than 15 additional estimated hours of effort.

Once teams learn more about how accurate they are with their estimates, and how many interruptions they have during the day, this slack number can go done or go up. The main intent is to only use a capacity number that helps guide to a commitment they can truly meet.

Finally, this should address you issue in item (3). There is no such thing as extensions in Agile. A timebox is never extended. Either work got done in the timebox or it didn’t. At the end of the timebox we evaluate the reasons it didn’t get done: it was more complex than we thought, the developer didn’t have the appropriate skill set, the tester wasn’t available, both developer and tester were pulled into an emergency. The timebox doesn’t change ever. What changes is what we commit to in the next timebox. Given that work wasn’t completed, what should we do in this next timebox.

Does this help?

(2) Perhaps your way of breaking down projects into pieces is entirely different than ours, but for us each piece is a different size so we may commit to anywhere from 10 to 20 assignments in our 2-week iteration for programmers and with 2.3 programmers per QA member, that makes double that for the QA role, so occasionally a programmer or analyst may help QA.

How can you have a set number of assignments? We vary because each person estimates how long each assignment will take them than fills up their commitment/allocation. The hours per iteration that we allocate is not 80 hours for programmers and QA, but rather 70 hours for programmers and 65 hours for QA because we answer a lot of questions for another department as well as do our work. We put in meetings and presentation/demo preparation time as part of those 65 or 70 hours to be fully allocated. That is, our issue tracking system handles bugs/defects, stories/enhancements, and tasks and each gets estimates of how long it will take the analyst, programmer, code reviewer, and QA.

(3) The downside of (2) is that if you estimate your hours incorrectly you have to talk to your manager and get an extension, which may result in a re-assignment of projects among the programmers, or you just have to work overtime. Because of this, over time we all became very accurate at estimating how long something would take us.

(4) The benefit of such estimating is that if it will take one programmer 8 hours and another 6 hours, you may want to have the programmer that will take less time get the project. This way more gets done and programmers work in their areas of expertise.