Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans

Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Hard Stop Iterations: No Where to Hide!

  • submit to reddit
One of biggest problems with the traditional waterfall model is simply it's length. It's a lot more difficult to understand how things went off the tracks when your project lasts for months or years. By the time you realize there's a problem with one part or one team, the root cause of the problem could've occurred last year. That makes it difficult to locate and fix the problem. The alternative seems like a lot more work, but has several distinct advantages.

First, let me ask you how long it takes you to drive to the beach? Got a number? Great. Now tell me how long it takes you to drive to work? Unless you're one of the lucky bums we all love to hate, your beach trip is probably measured in hours and your work drive is measured in minutes. Which one of these two estimates is more accurate? The shorter one is always a safer bet. The same is true with software estimates.

When a developer tells me that a task will take weeks or months, I know that the work hasn't been completely broken down, and the odds are good that there are hidden problems within the work yet to be done. These landmines tend to blow up and take your project's timeline with them. The only way to get great estimates from developers is to break down the long features into shorter tasks. I've found than nothing less than half a day, and nothing longer than a week, is a great rule of thumb.

Less than half a day is impossible to complete, generally speaking. Microsoft releases a service patch, your hard drive fails, or Apple releases a product you've got to read about all afternoon. (You know who you are!) These days I suggest that people have one day tasks. Anything shorter is probably overly optimistic (that's code for wrong).

But we also cap the amount of work we let someone estimate at one week. I really prefer three days and find it's the magic spot where people get their head around a problem. Anything longer than a three day estimate and you run the strong risk of glossing over details that aren't completely understood. It's those poorly understood details that blow up in your face and take days to understand and complete.

In a few days I'll present a few techniques you can use to drive down your estimate lengths. Let me know (in the comments) if this interests you. If there's enough interest I'll prioritize it.

So what does the hard stop iteration have to do with estimates? A shorter iteration forces you to consistently create shorter estimates. I really like one week iterations. It seems too short to do anything useful, but it's not. It creates a very regular rhythm for the team. Each week work is examined, accepted (or rejected or lack of detail), and tackled. If there's a problem, you find out at the end of the week.

That's another benefit... lots of finish lines! Have you ever worked on a project that seemed to never end? It dragged out for months or even years? Bugs, feature bloat, changes in direction... who cares why, you just knew you could never finish it.

With a hard stop, one week iteration, you get more finish lines. The team gets to finish something every week. It seems trivial, but the boost to morale can be significant to a team who's given up.

At the end of the iteration, you look at each task you've tackled (see my post on 3x5 cards), and decide if the feature is Done or Not Done. Each week you can find out if you're keeping up or falling behind. It won't tell us why a team is falling behind, but we'll know they are. That's good information to know.

At the end of the iteration, never automatically roll a feature into the next iteration. It was selected based on your assurance that the feature only costs N days. We've now blown that estimate, so the Responsible Person needs to reevaluate the feature based on the new (and more expensive!) cost. Most items roll back into the next iteration, but not always.

Risk mitigation is another great side effect of the time boxed iteration. How quickly do you want to know that team X or team Y can't complete their commitments? Or how quickly do you want to know they can?

We've touched on many topics here that deserve a much deeper treatment, but I'll save that for another post! Topics that tie in include test automation, smaller feature estimates, planning meetings, demos, and retrospectives. Which ones do you want to hear about first?
Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Matt Stine replied on Wed, 2010/04/21 - 12:08pm


OK, great. Now I want you to compare this to the iteration-less approach (or do you want me to do that? :-).


Jared Richardson replied on Wed, 2010/04/21 - 12:44pm in response to: Matt Stine

Hey Matt,

That would make a great future topic. ;)

Time boxed iterations are where most teams should start. Feature boxed iterations (or iterationless development) is a very advanced topic. I used to think it's where teams should start, but I don't today.

I like to start teams on a one week iteration and stay there for at least a year. Many teams will stay there, and others will migrate to the iteration-less model. Kanban can support this, as can The List (from Ship It! ).

In that model, you stop work when you have the features done that are needed for a given release. The very real danger of that model is the same for waterfall. Between problems and feature bloat, you never finish and you never ship. Until you really know what you're doing, stick with time-boxing. I think your team would do fine, but it's not where I like to start teams.

How's that?


Sri Sankaran replied on Thu, 2010/04/22 - 1:01pm

We have been working with 2-week iterations on our current project to great success. It also helps to have a clear definition of done.

I agree that any task estimate that is beyond "a few days" has an involuntary fudge-factor. Panning poker also helps increase the accuracy of the estimate.

The rub however is being able to deliver a go-live date to the customer well in advance. I'll explain the emphasis on the date in a sec. On our current project, based on the deliverables we negotiated with the customer (in December), the best we could commit for delivery was "2nd quarter of the year". It wasn't until recently that we were able provide a concrete date. And even then what we are delivering and what we had originally negotiated are slightly different. This latter part isn't such a big deal because the customer knew what was going on due to our constant feedback.

The reason we cannot provide a concrete date well in advance is that that requires thorough evaluation of all the tasks that are lined up. However the agile prescription...ok, the agile prescription the way we're interpreting it calls for what I term voluntary myopia. We prioritize the tasks and choose to focus only on the subset of the tasks on hand. The premise here is that minor course corrections are easier (and less costly) than the big design up-front (BDUF). I would to tend to agree with that.

So, can one deliver a completion date at the outset or should I educate the customer that the fidelity of our estimates will increase as we work through our incremental releases?

Jared Richardson replied on Thu, 2010/04/22 - 7:58pm in response to: Sri Sankaran

Hi Sri,

There are three factors in delivering software. We must balance ~time~, ~features~, and ~quality~. In most cases, you can only have two of three (at best) under your control. Any attempt to control all three factors is simply folly and generally fails.

In your case, we know we don't want to slip the quality. No one wants to ship buggy software. And the customer specified the feature set. So the only remaining factor to adjust was the time, and it sounds like your customer was willing to accept that.

If the customer (or your sales team) can't allow the dates to slip, then they need to work with your team to make sure the Must Have features go in first, then the Want To Have, and finally the Good to Have features. Towards the end of the product cycle your customer will pick and choose which features end up in the product and which don't make the cut off date. This sometimes feels bad because the customer isn't getting everything they wanted, but in reality it's much better. The customer can pick and choose which features they want very late in the game. With big up front design, they have to choose their features very early in the product cycle. If the last year or two has shown us anything, it's that the world can change dramatically in a short amount of time. Allowing a customer to prioritize on the fly ensures they get the product they need, not the product they needed last year.

So can you pick a ship date early in the cycle. Sure you can, but you've got to have a flexible feature set.

Can you have a solid feature set? Sure, but you've got to have a flexible ship date.

In most cases, you'll want to blend the two approaches and get the core features the customer needs out the door as quickly as possible.

And of course, this all assumes that you won't compromise on quality. I've seen many "customers" (internal and external) ask teams to compromise on quality, but after the software ships, everyone blames the dev team for their perceived incompetence. No one remembers asking you to compromise, just that your code wasn't good. Never ship crap!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.