Nathan and I were discussing the abuse of burn-down charts on Twitter. He asked an important question: How do you know a story is too big before it is too late?
Since this was twitter, I’ll expand the question a bit: How do you know a story is too big to finish before the end of a sprint?

Why you need to know
Birthday parties and winning lottery tickets are dirt trail surprises. Finding out at the end of a race that a feature isn’t complete is a bad surprise. And bosses, clients and PO’s don’t like bad surprises. In fact, as the leaders, you don’t like them either.

Here are three quick ways to avoid a bad surprise.

1. Go small.
To avoid unhappy milestones, break up your stories into “inch-pebbles.” Johanna Rothman recommends this method as an alternative to “milestones.” (See the wordplay?  She’s smart!) .
Smaller stories show consistent progress, are easier to track and adjust.  They are also simpler to fix when things go wrong.

My vet recently told me, “I like small dogs better. Big dogs are harder to control, have bigger poops and make bigger messes. Little dogs are easier and better in all regards.”  Stories are the same way: smaller is better. In fact, I’m waiting to see a team create stories too small to be practical. If you’d like to send me some, then I can cross that off my bucket list. 😉

2. Re-estimate often.
At your daily stand-up add in the simple question: Has your estimate of this story changed? If someone says “Yes,” follow-up with them to ask “Why?” They may have learned something new or found a hidden dependency, or the estimate was just wrong. No matter why it happens, you now know the story is at risk of finishing.

You could have the team huddle to discuss the story. You could re-estimate it. You could notify the PO about the new information. Either way, re-estimating prevents bad surprises at the end of a sprint.

3. Watch out for the cliffs.
Your code has a geography to it that you need to understand. Some parts have wide open spaces with green pastures. Some have rugged cliffs with 100′ drops into the ocean. Some places have well-worn trails; others need you to clear brush as you go.

If you know your codebases geography, you won’t treat all story estimates the same. You can remind the team that “there are sharp rocks there” or “be careful that we don’t fall off the cliffs again.”

To a novice, all code looks alike. But you are not a novice. You are an expert, and you know the landscape. In fact, many of you know it better than your team!

Help them out by reminding them of geographical features as they estimate. Knowing the difference between a paved road and a dirt trail should affect the assessment.

How often do you get a bad surprise at the end of a sprint?
How does your boss/client react?