Issues are defined either by a member of the development team or our Product Owner (in Scrum Terms) in cooperation with at least one member of the development team. In (depending on project or team) weekly or bi-weekly sprint meetings we set the development targets we want to meet in the current sprint and select those issues we want to tackle.
Each member of the team reports on their own velocity and capacity for the current sprint, that is, how much work they think they will be able to get done. For this they take into consideration which days they will work, their meeting schedules, holidays and other things that might impact it. Based on that estimate for the whole team, issues are selected.
Each issue is rated by each member of the team, and once a concensus has been found, the rating is applied to it.
This ensures a good relationship between development speed and quality of the code. Thus, we are able to deliver products from the drawing board to paying customers within weeks.
We utilize issue weights and planning poker to rate each issue we come across for the sprint as a team with each member getting a vote. If there is any discrepancy between the perceived complexity of the issue between members of the sprint, we discuss them to make sure there is a shared mutual understanding of where the problems and challenges are.
Ratings are fibonacci sequence numbers between 1 and 5, that is: 1, 2, 3, 5. We do not utilize any other ratings and instead opt to break them into smaller issues if possible. A rating of 5 we approximate to be about half a day of development work, a rating of 3 signifies several hours of work, a rating of 2 approximately an hour of development work and a rating of 1 signifies a usually trivial amount of work.
We only ever rate development work without time for review or deployment. Instead we assume that the next higher rating will be an approximate estimate of the total effort if all the work 'around an issue' is added to the development time. Thus an issue we agree on to be a 5 is actually tracked as an '8' and so on.
Velocity & Capacity
As velocity we describe the amount of issue weight a person can manage to accomplish per working day. This should include an average of disruptions, other duties, meetings as well and thus should be expected to not be equivalent to 8 full-productive hours per day. Track your own velocity from sprint to sprint and change it so that it becomes a more and more realistic estimate of your real work productivity each week.
As capacity we estimate the amount of issue weight a person can manage during the current sprint. If for example we do weekly sprints, they usually contain five working days, thus the capacity should be five times the velocity in usual circumstances. If there are holidays, time off, large excursions and so on, capacity for the sprint should be adjusted. All members of a team should report their personal capacity for the following sprint before the sprint planning to the sprint leader.
The sum of all team members is then used to estimate which issues will fit inside a sprint and which do not.