Over-commitment

When I wrote the “Long time, no see” post in December I was planning to resume writing regularly (at least bi-weekly) but since then I’ve only managed one. I thought I would have some spare time that could be put towards it but other things got in the way.

Does that sound familiar? How many teams start a sprint having planned to complete a number of things, only for that plan to go awry? If your team hasn’t experienced it yet, then it’s just a matter of time before you do… or maybe you’re playing it safe and you have a second planning session mid-sprint.

I’m not saying this is a bad thing – stuff happens and not adapting would be worse. Sticking blindly to a plan and ignoring reality sounds ridiculous and yet many organisations still do precisely this.

So how can we reduce the chances of our plans being impacted? Plan smaller steps; discuss risks and dependencies as part of planning; understand your capacity; and say “no”, or at least “not right now”.

Plan smaller steps

If you plan once a year (e.g. an annual budget cycle) then try moving to quarterly planning. If you create quarterly roadmaps that describe what needs to be delivered, then break it down into smaller feedback loops. If you’re a scrum team that plans four-week sprints but finds yourself replanning during sprints, then try two-week sprints. Whatever your cadence, if your plans often need updating then try a shorter timeline. It’s also possible that your plans are too detailed or rigid; there needs to be room to adapt based on learning, discovery and feedback. This is also why there are multiple “planning layers” – the team meet (at least) once a day to coordinate their efforts, share new insights, identify obstacles and make adjustments as needed. The shorter these feedback loops are, the sooner the team can respond.

Discuss risks and dependencies as part of planning

Sprint planning isn’t simply for the team to decide what “fits” – there should be (or have been in preparation for planning) discussions about the risks, assumptions, issues and dependencies. The somewhat-controversial Definition Of Ready is a good place to keep a list of reminders of the types of things to consider, e.g. if it takes a while to get access to a particular system, then make sure the team knows to start that process ASAP (in extreme cases, it may mean postponing a story until the access is granted). What else might throw the plan off course? It’s not possible to predict and anticipate everything but the team should learn from past “gotchas” and try to avoid repetition.

Understand your capacity

Even if everything goes smoothly, there’s no point in planning for more than could be realistically achieved. If a team uses story points consistently, then they probably have a good guide as to their capacity. Even without putting a number on it, stable teams should have a good feel for what is possible. The trouble with both those approaches is that teams can believe (or be cajoled into believing) that they can do more “just this once”. Forecasting (e.g. using cycle time) is based on the reality of historic data and is less open to “interpretation” or wishful thinking.

Say “no”, or at least “not right now”

The previous steps can help improve the likelihood of success, but one other defining factor is whether the team feels they can say “no” to taking “just one more thing”. If they feel they have to say yes to everything then there is no true commitment. (I know commitment is a controversial term; I’m using it as a shorthand for what the team tell those outside the team what they believe is achievable.)

In short: don’t make promises, because things change. Small steps with frequent feedback let your customer/sponsor see progress (which should lead to increased confidence) and collectively you can make adjustments based on new information.

I’m not committing (out loud or even just in my head) to updating this blog every two weeks, but I will try to write when I have time and have something to say. 🙂