TL;DR: When planning sprints, don’t pack your ‘nice to have’ features in the end. Pack 20% of each sprint with ‘Nice to Have’ or ‘candy’ features, so you can throw them away.

Planning sprints is a mixture of an art and a science. It’s hard to get all of the features you need (and some of the ones you want) stuffed into a development cycle. One of the tools I use to keep a project on track is making sure I have sacrifical features (or tasks) in every sprint, usually accounting for about 20% of the spint goals.

Lets say you have a project of 12 sprints, and 20 ‘dev points’ per sprint. A pretty normal breakdown would be to have some core features(red, 60%) and some should-have features (yellow, 25%) and a some nice-to-have features (green 10%). Oh and a little candy (blue 2%) as well as some tools (purple 3%) to build. I know this is a bit of a simplification, but I think if you know sofware, you get the gist. So go with it for a min.

Naive Sprint Packing

Now, your newbie SCRUM master will try to plan out a set of sprints for success. Naturally, she wants to get ‘Core’ done, then tinker on nice-to haves. So she plans the project as:

Looks nice right? Get hard stuff done first! If that seems like a plan for success, you probably haven’t run many sprints. To begin with, you can’t build all core fetures in a block. Any time you have interoperation, you have two choices: Define everything up-front (and fail) or make a basic design and evolve (and fail less). See Also ‘Waterfall Model Considered harmful. Core features are not as parallizable as ‘side’ features.

So, that red block of project will creep, or get delayed, just by the nature of development. Once that happens, each update to managment, and time you check your timeline, it will end with ‘and we are behind on Must-Have A,B, and C’. Every. Update. For weeks. As a hacker, you may know that is not bad, and it’s just lag from the front end, but to management and to your not-as-logical-as-logical parts of your brain, what they hear is ‘FAILSAUCE’.

Intermediate Sprint Packing

A more experenee scrum master will break things out a little more, and do something like this:

Again, it’s getting better. Now when things drift, they are more likely to be yellow items, so it’s not such a failure, and you can cast those off. But still, I bet 3 months pay that 99% of projects (yours) will be behind by sprint 8. Instead of red, Yellow items are failing, but still, there is fail.

Advanced Sprint Packing

A more experience scrum master is going to spread things out even more, and make sure, every step of the way, there are tasks that can ‘fall off’ a sprint, without killing the final deliverable.

Every sprint will go bad. Unless you are both awesome and amazingly lucky, almost every spint some core-task will go over estimate. Those red tasks are going to be on the plate almost every sprint. And every sprint you will have some Blue/Green tasks to throw away. Why? Because your estimates will be wrong, mistakes will happen, and you want to throw some luggage overboard, and make the product skinnier, instead of having late items the whole project long.

When you pack your ship, keep some extra luggage around to throw overboard during the journey!