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."

Deadline: Friend or foe?

Deadlines are a double-edged sword.

Without deadlines there would be no pressure to get a project finished. Projects without deadlines can continue forever, as people continuously add features and try perfect the product.

More seriously, work tends to fill up all available time. So, if there is no deadline - or a very generous deadline, all the available time will be used up; and the project will still have trouble getting to a finished state.

On the other hand, deadlines create pressure.

• Some people don't work well under pressure, and their work would be better if there was no deadline, or a very far-off deadline.
• Deadlines cause people to take shortcuts, in order to meet the deadline. This could be a a pity, if the deadline is fictitious; it simply means that the project will need a follow-up project to clean up from the mess caused by the deadline.

When working in continuous-release mode, deadlines can be ignored. Whatever is ready by the release will be shipped; whatever is not ready will wait for the next (soon to be) release. However, a Master Schedule with best-case guesses is still a good idea, if nothing else so that you have a list of what needs to be done in which order, and to track how far you are from completing the project.

This concept of projects without a deadline will have the side affect of dividing the team in 2:

1. Those who continue to work fast, and always have their part of the project ready as expected. When they miss a self-imposed deadline, they will try catch up the lost time, or apologize.
2. Those who take advantage of the freedom, and see no reason to speed up.

It's obvious which half of the team you will want to replace, sooner rather than later.

- Danny