Setting priorities

In Agile development, milestones are typically 2 -3 weeks long and are called sprints.


Before each sprint, the team gets together and decide what needs to be done. Typically, the Product Manager will have a backlog of tasks from which to choose from.


Obviously, urgent tasks that will make a noticeable difference to income, traffic or user experience will get priority.


However, less-important tasks also need some attention, otherwise they will never be done.


The date at which a task was first presented to the sprint-prioritization meeting should be noted. If a task has been presented 3 or 4 times and is still in the queue, then a decision needs to be made:
Either do the task in the coming sprint, or delete the task.
If a task is simply being mentioned for old times sake, and everybody would like to do it but nobody has the time, and nobody can see the urgency, then it is simply taking up time in the prioritization meeting.


Since we live in a dynamic world, not every task can be planned 2 - 3 weeks in advance. That is why a typical Kanban board has more lanes:

1. Emergencies and Showstoppers. 
• Either the live system has become unstable (e.g. web site down,under attack or slow) or a 3rd party wants something urgently (e.g. a tracking code is being changed, a seasonal ad campaign was suddenly signed)
• This is not to be used for VIPs to push their pet projects; those have to be approved at the prioritization meeting.
  
2. Legacy bugs
1. For bugs that are found in code that has already been released. If these are added to a sprint, then eventually no new work can be done in sprints as all available time will be used for legacy bugs. Therefore, legacy bugs need to be taken care of in parallel to the sprints.
3. Maintenance
• Time needs to be allocated for maintenance of systems without becoming the man focus of the team, similar to the philosophy of legacy bugs.

These 3 types of incidences need to be attended to without affecting the sprint's schedule. With experience, a Project Manager will become adept at predicting the unpredictable and will know how much slack to add into the schedule.

Once a team has agreed to its upcoming sprint, an atmosphere should be created  to ensure that the team can focus on its sprint, and realizes that it is expected to meet its commitments, come what may.

This is easier to enforce if the major players involved are in attendance at the prioritization meeting, and they they each have a say in defining the sprint.

If management are in the habit of interrupting sprints with special demands, then they should also be present at the meeting, so that they can later be confronted with "But you agreed to the scope at the meeting. Please keep this for the next sprint."