Aggressimistic planning

We became interested in this problem after a run of two-week sprints in which not all the work was completed. The difficulty was usually dependencies that did not turn out as expected, rather than underestimating the effort needed to complete individual tasks.

Reducing the commitment looked like giving up on ambition. Keeping the commitment meant repeating a plan that did not work. We needed a way to do better at both.

Be pessimistic first

Consider all the problems that could reasonably occur: platform instability, deployment failures, illness, and delays to dependencies outside the team. Reduce the scope or change the approach until the plan can survive those possibilities.

This matters especially when another team must create something before your work can proceed. A dependency on a mature production service is very different from a dependency on someone else’s unfinished work.

Then be aggressive

Once the plan is grounded in reality, look for the greatest achievable scope. Challenge unnecessary work, resolve dependencies and choose approaches that make delivery faster.

Pessimism alone can produce a cautious plan that leaves the team bored and stakeholders disappointed. Aggression alone can produce enthusiasm followed by missed commitments and exhaustion. Combining the two means pursuing delivery as fast as it is actually possible.

Look for simplicity before more effort

When refining work, we found it useful to distinguish three kinds of solution:

1. A solution requiring minimal or no development work.
2. A solution requiring clearly specified, achievable development work.
3. A solution for which it is not yet clear what work is required.

The third kind should not enter a sprint as though it were the second. But creating more investigation work is not automatically the best answer either. First look for a simpler solution that removes the uncertainty altogether.

The order changes the conversation

If you start with an aggressive plan, people can become attached to a scope that cannot be delivered. Adding realism then becomes a battle over taking things away.

Start with a realistic, cautious plan instead. Stakeholders who want more scope can help find the resources or resolve the dependencies needed to make the plan more aggressive. The discussion becomes a practical one about how to achieve more.

Keep the week connected to the bigger plan

Completing a sprint and meeting a release deadline are different concerns. Confusing them damages both. Dependencies need attention while the work is being defined; the sprint itself becomes more predictable when that work has been done.

Our preferred attitude is to be deliberately pessimistic, and take the necessary actions, while planning. Then the team can afford to approach the work with confidence. A difficult plan should be an invitation to act, not a reason to give up.