Your team won’t have a traditional task backlog if you stage it out through scheduled iterations.
Staging your team’s task backlog into scheduled iterations is an important part of managing your project to intermediate milestones. Atomic’s teams commonly decompose a project into a backlog of tasks that can accomplished in a day or less. Backlogs will have detailed tasks estimated for the near-term and larger chunks staged for later work.
Doing it Wrong – Scheduling from the Backlog
I suspect many agile teams schedule tasks one iteration at at time. Tasks sit in a backlog until the current iteration is accomplished. When a new iteration is defined, the team will select tasks from the backlog and schedule them for the upcoming iteration based on the team’s velocity from previous iterations.
It’s easy for a team to feel indifferent if a task isn’t accomplished during an iteration. Especially if the project spans many months. Velocity might suffer slightly from the previous iteration, but the team can easily move the task to the next iteration. Fewer tasks from the backlog make it in to the upcoming iteration, and the delivery schedule might drift slightly.
Schedule drift can continue for multiple iterations until scope needs to managed (cut) in the backlog to keep on schedule. It’s disappointing that the scope being cut may be related to differentiating features of the product.
Eliminating the Backlog
I believe there is value in eliminating the backlog and staging tasks and epic stories for the current body of work. Milestones should be established at the start of a project, and all tasks and epics should be associated with a milestone. Detailed or ballpark estimates can be used to identify a delivery schedule based on a predicted velocity.
Iterations should be staged with detailed tasks, and milestones should be called out in the iteration where they are scheduled to be accomplished.
A team may find that each iteration has 5-8 tasks staged in it. A team will feel the immediate impact of drift if a task isn’t completed and needs to move to the next iteration. Because the next iteration had been previously defined, the team feels the pressure of the iteration having more work scheduled than velocity forecasts as feasible.
The near-term schedule pressure will cause a team to take more frequent positive action on scope management. The team can discuss their confidence to complete the iteration as scheduled. If the team doesn’t feel confident, they can discuss how to appropriately manage scope within the iteration or future iterations in order to preserve the schedule and optimize effort given to high value features.
How Do You Roll?
How does your team manage their task backlog? Do you define new iterations as they occur or do you stage out your project? What are the pain points and benefits you find in your approach?