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.
In order to learn from our mistakes, pro-actively tackle our problems and improve our processes, we do a Sprint Retrospective at the beginning of each sprint. All development team members write two to three things that went well and/or went badly in the past sprint period on a piece of paper.
All the points are collected and discussed between the members of the team and together common problems are identified. Plans for improving these issues are written down and hung up prominently so that everyone gets reminded where problems occurred and people focus on trying to solve them.
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 consensus 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 21. Issues can then be compared between each other so that developers gain a sense for how big certain issues are, based on their prior experience. A developer estimating an issue as 8 points can then imagine it taking the same time as two issues, one with 5 and one with 3 points. The frame of reference for how long that will take in days is then somewhat individual for each developer.
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.