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

Sync up in 15 minutes: The daily stand-up

The more people involved in a project, the harder it is to keep everybody in sync.

Sending status updates by email sounds like a good idea until you try it. At some point (after about 2 emails) most people stop reading them; they seem so repetitious.

Having a meeting should work, but it is very time consuming, and to be effective everybody needs to be persuaded to arrive on time. In reality many people's minds start wandering during meetings, unless their specific part is being discussed.

What does seem to work is a daily 15 minute stand-up:

• Daily: This way the updates are short and few, allowing people to concentrate.
• 15 minute: This wastes little time and gives people an incentive to arrive on time, else they miss the entire meeting.
• Stand-up: Once seated, people are happy not to move for a while, and meetings can drag on. When standing, people are happy to end the meetings quickly.

Where to do the meeting? We used to do the meetings at the Kanban board which had all the tasks laid out on sticky notes. This way tasks can be moved from the "pending queue" to "in progress" to "ready for testing", "in testing" and "ready to deploy".

What is the point of this meeting?

• Status update: Who is falling behind and maybe needs help
• Either help with the current task; shrink the scope, or add manpower or group thinking
• Or else help with the task queue; hand over some future tasks so that the same person isn't an eternal bottleneck
• Schedule update: When does it look like we may be ready to hit the next milestone
• Milestones can also be redefined in real time if needed
• Attendance: Who will be away in the coming days, who is on sick-leave and may need help with outstanding tasks.
• Implementation feedback: informing the team how something was implemented (in 90 seconds) so that good ideas can be adopted team-wide and bad-ideas can be caught early on.

Invariably issues will arise that will take a while to discuss. After about 60 - 90 seconds, the Project Manager should make a note of the issue and then declare let's take this offline.

If needed, a meeting can be called to further discuss the issue. Otherwise, after the meeting has ended, the relevant people can be asked to stay on and finish discussing the issue. This allows most of the people to return to work, while those interested and/or involved can discuss the issue at leisure.

At the next daily stand-up, the conclusion of the meeting should be announced.

At Answers.com we often had 2 or 3 15-minutes stand-ups scheduled one after the other. This forces them to end on time.

After each meeting, the Project Manager must send around the meeting minutes. I used to reply-to-all to the same email every day, with a few updates.

Sometimes sending the same email with today's changes in a different color is effective.

A chart can be used with a new column for each meeting, with a maximum of 4 or 5 days worth of history in the chart at any time.