6 Tips for Improved Agile Scheduling

The definition of a project includes having a start and an end date, making a project a temporary endeavor.  Even though more flexibility is required for agile projects, senior management may still have an expectation of some form of high level schedule so other projects in the organization can be planned.

This means that in addition to getting the best possible requirements up front, you will need to plot out the various work activities accordingly.  Here are 6 tips to improve schedule management for agile projects:

1. Only current and near-current tasks can be accurately planned.  Only the current and possibly the next sprint will have accurate planning for time.  Due to the flexible nature of agile projects, today's sprint may add more work to a sprint further in the project. Be aware of this constraint when determining work in progress limits and scheduling external events.  Measuring with a burn down chart will help inform work in progress limits, which in turn, will improve planning of future sprints.
2. Gantt charts are for high level planning only. Gantt charts or milestone plans should have a limited role in agile projects.  They can be used to time box initial requirements and planning time, roughly plan sprints (be sure to include time between sprints for backlog reviews, retrospectives, and demonstrations), and time box project close out activities.  Any other use is just wasted effort since each sprint is likely to see some changes during the course of the project.
3. Schedule tasks involving external resources or teams.  In addition to the high level plans for sprints and other items mentioned above, it is also important to schedule tasks with external resources and teams so they are properly managed.  This may mean work such as demonstrations attended by more customer representatives than the product owner, outside consultants, and third-party teams responsible for some project work.
4. Drive scheduling with requirements and ...  Work planned for sprints is generally requirements driven by the product backlog.  It's the "agile way."  Be sure, however, to make sure the team knows what this includes.  All the work must be tested and of good quality, meeting all acceptance criteria (e.g., the definition of done).  Time for some rework should be considered.  Any discovered requirements for interoperability (e.g., all subroutines simultaneously write to a common file) will also need added testing.  Finally, be sure that time for the agile event of demonstration is included for the end of the sprint, especially if the demonstration will include a broader audience than the team and product owner.
5. Don't forget final integration and acceptance testing.  I've worked with several agile teams which had the mistaken belief that they had a quality project which would work because they unit tested all their work.  This is a an agile myth!  I've hardly had a project in 30 years that worked perfectly in the production or end-user environment.  Expect your project will experience the same.  Be sure to include some time for final integration and acceptance testing in a production or near-production environment.  It will spare you and the team the embarrassment of the customer finding mistakes.
6. Include all project closure work.  The project manager and often the team is best remember for the final delivery.  In addition to final testing, be sure there is time in the schedule for final documentation, training, demonstration, any turnover activities, and possibly rework.  While the dates may change as the project progresses, these items should be in the schedule from the start.

As you begin to consider managing the schedule for an agile project, you may also want to review these additional, related articles:

The Time Frame for Total Project Completion

4 Critical Agile Events

5 Tips to Improve Your Agile Project Management

Building an Effective Plan

Agile Planning: Best Practices for Project Manager