Skip to content

Demystifying Agile: Rants of a Madman – Getting Started – Sprint Planning Like It’s 1999

May 9, 2012

Why is it that if Agile is supposed to help us have more visibility, be more predictable, and deliver higher quality software that delights customers that so many teams still fail to realize these benefits? I’d contend that it is because many expect Agile to be a silver bullet to solve all of their planning, tracking, and execution issues. One issue that still seems to impact many teams is the inability to proactively plan for “reality”. That’s right, the simple concept of not planning for “stuff happens” while planning “Happy Path Sprints” has been the demise of many an Agile team.

Riddle me this: If you have a backlog of stories and you are planning a Sprint, why would you load up the Sprint with every Story that might fit? Really? You’re planning to fail with each and every Sprint.

First of all you know your estimates are probably wrong. Secondly “happy path” planning never works—something will always go wrong and consume time. If you load up your Sprints during Sprint planning with all the stories that will fit you are guaranteed that your Sprint will fail to meet its goals as something will always fall out. Worst case, you’ll never reach that opportunity where you finish the work in a Sprint early and pull in extra stories from the backlog, which delights your customer even more.

I could just shoot the Agilists who teach teams to load up their Sprints with all the stories that’ll fit because “well if you don’t get to a Story, that’s okay, you can put it back in to the backlog for a future Sprint.” That works for Agilists contractors who are all about billable hours and are quite happy to take your money as more and more Sprints are added to a release, but in the real world it is a recipe for disaster. If a team is constantly pushing stories out of a Sprint or they are being forced to finish the stories within a Sprint at all costs then that team is doomed to fail.

Good Sprint planning is about being realistic. It is about knowing what the realities are for your team and factoring them in to the planning cycle. It is also about setting expectations, setting governors based on those, and then sticking to them until you have enough data behind you that suggests that these governors should be changed.

So let’s assume that your Agile team is also responsible for production support and history tells you that on average your team spends 40% of their time fighting production fire drills. We can get all philosophical as to why this shouldn’t be the case, but if it is the reality for your team you just need to declare it as being that way. So why in a Sprint planning cycle would you load up 100% of your time with stories? Doesn’t reality say you should only load the Sprint up with 60% of the stories that would fit, leaving the other 40% for “stuff in production happens”? Yes, you could load up all your time, but at the end of the day isn’t about 40% of your time being spent on things other than your stories just going to push those out in to the backlog anyways? Why not give your team something to celebrate and plan for the 40% “distraction from stories” time and declare victory when you find that you had a great week and can actually pull in Stories form your backlog?

The other reality some Agile teams don’t plan for is the simple truth that “defects happen”. I don’t care how great your Story demos and acceptance criteria are: You are going to have defects that will take time to fix. Now one approach is to save all of that up for Hardening Sprints at the end of the release. I like Hardening Sprints, but I think this is a misuse of them. If you are driving for quality up front why wouldn’t you reserve time to repair code during your Sprints, fixing as many defects as you can as you go?

I knew a team once that reserved 33% of their time for new stories, 33% of their time for defects, and 33% of their time for production support. Basically in a 3 week Sprint they planned their Sprints on allocating their time in this way. Management hated it at first, but the reality was that it was the answer that was correct for that team. Before doing this the team found itself lying to themselves (and their shareholders) about what new stories they would work on for a Sprint and then end up finding that 33% were pushed in to backlog each and every week. They also had to add a number of unplanned Sprints at the end to “harden” the product, but that wasn’t very fulfilling to the team and smelled like waterfall renamed. It was also as unpredictable as waterfall. Once they changed their Sprint planning to simply splitting their Sprints in to thirds everything changed for them—they were actually much more predictable, had higher quality, and at the end of the day their products actually did ship “on time” given there were no unexpected re-plans. Over time they also adjusted these Sprint planning governors as they got better and better and became a well-oiled engine. The last time I checked they ended up allocating 65% on new stories, 25% on defects, and only 10% on production support as what they were pushing in to production was of higher quality. It is a set of percentages that they look at and review to this day.

Lastly, you may also have the case of “mandates”. Those are usually a set of stories that must finish before a given “drop dead” date (perhaps to comply with regulatory deadlines, marketing launch, etc.) in terms of when those stories have to be delivered. Sprint planning needs to take mandates and these compliance dates in to account. Stories for mandates, like all other stories, consume time and resources. It is not a matter of working your stories in a sprint and then also working mandates on top of that; it is a matter of prioritizing all stories since stories are stories. If you run the calendar backwards, and you have appropriate governors in place with each Sprint, you can then plan which mandate stories should get prioritized in to your Sprints. No room in the next Sprint for a mandate story that must be worked? You don’t simply suck it up and work it in addition to your other stories. You kick something else out of the sprint being planned and put it back in to the backlog to make room for the mandate story: by definition mandate stories are higher in priority.

So, are you going to continue to try to shove 40 lbs. of Stories in to a 15 lbs. Sprint bag or are you going to shove in 11 lbs. knowing that 4 lbs. of other distractions will fill the bag for you? Each team’s guiding planning governors for their Sprints will differ (based on the reality for that team), but I can guarantee you one thing: Loading all the Stories that could fit in to your next Sprint without taking in to account the realities of the team’s time during Sprint planning is planning for failure. Don’t do it… Don’t sprint plan like many might have done in waterfall back in 1999…

About this series: I love Agile; I also hate Agile. I love how it can free teams to truly delight customers while delivering high quality products on time. I hate how Agile zealots can use the Tower of Agile Babble to confuse the heck out of teams trying Agile on for size. My goal is to help new teams actually embrace and become Agile without having to learn all of the pomp and circumstance in one big fat swallow.


From → Agile, Software

One Comment

Trackbacks & Pingbacks

  1. Are HiPPOs Hijacking Your Team?! « agilesutra

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: