What Happens When You Can't Finish What You Wanted in an Iteration?


I ran a little workshop today about transitioning to agile. I was talking about timeboxed iterations, and one of the participants asked this question. “So I don't quite finish one of the features I want to finish in this iteration–and it's the end of the project. I think it's going to take me a couple more days. Do I extend the iteration or do another iteration?”

I said, “End the iteration at the end of the timebox.” There are lots of good reasons to do so: retain the reasonable pace and rhythm of the project, be able to gather data to compare this iteration to previous iterations, and to see why the team thought they could finish all these features in an iteration but couldn't.

The participant didn't agree with me. He has deliverables to other people. He can release at the end of an iteration. If he starts another iteration, why should people wait 4 more weeks rather than 2 days for the release?

Aside: I've never seen a 2-day estimate at the end of the release actually finish in 2 days. I've always seen it take several weeks. But let's assume it really is just 2 more days of work, and feature is the only thing left to do. He could start another timebox and end it early. Or, why not just use an interim build as the deliverable, if the build is not for an end customer?

The class had a vigorous discussion about whether to end or continue the timebox. I hope that he tries ending the timebox when the time is over–otherwise it's not a timebox. It's too easy to let this iteration go over by a couple of days, let the next one go over by a week, and pretty soon you've got 5-week, 6-week, 7-week iterations, and the value of being able to do iteration re-ranking of features and the ability to make releasable software every x (here 4) weeks is gone. You've got something that looks like a staged delivery lifecycle, assuming you're integrating as you go.

So, what do you do if you have just a little bit left in an iteration? I suggested that aside from ending this timebox on time, that they reduce the timebox duration to two weeks, and see if that improves their estimation and iteration planning. (My concerned participant was not excited about that option.) If you have experience with this, please comment.

Labels: iteration, timebox

10 Replies to “What Happens When You Can't Finish What You Wanted in an Iteration?”

  1. My experience coincide with that you said: as soon as you “break” the timeboxes, you lose them and is very, very difficult to start using them again.
    The only possible remedy is to know ASAP that a feature will not be finished in the timebox, and start the negotiations with the “client” (whoever is waiting for the software).
    These are some contingency plans that can be triggered and I have found useful in the past:
    * Work “a little more” daily (no more than one hour/day) to try to hit the mark.
    * Switch developers, with a transition period (perhaps the original one is in a blocked state).
    * Negotiate a partial delivery, and a follow up with the finished feature.

  2. Wow. I had this EXACT conversation with my team today. The team wanted to Slip and I pressed for another iteration. Oh yeah, worth noting – we are supposed to release after the current iteration. So its very similar to what you have described. AND the lead developer came to me afterwards and told me it would just be a few days. But I told him I thought we should plan a complete 3 week iteration.
    This post just freaks me out! Wow.

  3. In my opinion, an organization that can’t handle this sort of problem doesn’t really know agile. Agile is all about discipline and constant adjustments. One of the main reasons for time-boxes is to force us to think creatively, on the fly, about how to meet them.
    We should expect to fail to meet our original objectives in some iterations. When we can’t meet those objectives, we change the objectives such that they are (1) achievable within the time-box and (2) yield something “releasable”. Inability to make this sort of adjustment indicates a failure of imagination.
    That said, I think a healthy, experienced agile team can adjust time-boxes slightly. But the scenario you describe sounds much more like a failure of discipline and creativity than a candidate for slipping the time-box.

  4. I concur; as Kent Beck says, “Slipping dates is addictive.”
    If for some reason we absolutely can’t get the feature done in time for end-of-iteration — and we will slip that a few hours and make people wait for their ice cream, but never into the next day — we tag/branch the iteration in our SCM and move on. The thing that didn’t get done is still top priority, so work continues on it and if it does get done in only “another day or two”, then we will merge the appropriate changesets back to the release branch.
    Of course, this works for us because our “release” is “release to QA”; because of the nature of our product we have a 6-8 week QA cycle on top of our roughly 10,000 automated acceptance and unit tests.
    P.S. In case it makes a difference in understanding the above, our end-of-iteration falls on Monday, with iteration planning on Tuesdays. I think this is because of some Agile book I read suggesting it because “everyone hates Mondays enough as it is, don’t fill it with meetings too.” I’m not sure that makes much of a difference for morale, but it does mean that there’s continued development momentum crossing the iteration boundary without an intervening weekend.

  5. Well this is something I had being facing for quite sometime but not frequently though .. and what a good thing to come across this blog post..
    So based on the type of product and release we Map we have a contingency application to the End Of Iteration at the End of Project we really call it as a Quality Week . This week is being used for all such delays as mitigations and otherwise being used to improve the Quality of the deliverable (cleanups, refactors, code reviews, retrospectives and much much more) the later is the primary goal. We keep this Quality week in sandwich of every 2 Iterations which helps us in catching up things and at times this quality week is flexible enough, in the sense we dont use them for first 4 iterations and then take the 2 quality weeks by end of the project to deliver more quality code…
    So Yes I agree that failure to achieve features done in the timeboxed Iteration is expected and as Agile organisations we have to foresee and adapt it even if we have to strech or schedule a new timebox for such scenarios.
    Sameer Shaikh
    P.S. I was thinking of having the Iteration starts on Wednesday to cover the Risk of fetures not completed in time, which gives 2 advantages really:
    1. Fresh mind on Mondays to continue with the feature development targetted to finish on Tuesday
    2. If we foresee delay weekend can be used.

  6. 1. I’ve seen features/fixes which required 2 days to be developed and released.
    2. I’ve been in situations when on the end of our timebox we were lacking several features and having another iteration just wasn’t an option. When your software isn’t adjusted to law changes which comes into force and you can choose between lengthening current iteration (a week) or having another one (4 weeks), there’s actually no choice.
    3. I believe that when the team is truly agile (not just staring blindly at the Manifesto), thay can judge the situation and decide if exceeding the timebox is a good solution or not.
    4. With the example you’ve given it’s really hard to judge which answer would be the better, what means that I don’t agree with your auomatic, always-good answer to finish timebox on time. You said you didn’t trust the participant’s estimate. Why?
    5. Thing I agree with you is that inviting a possibility to let the iteration go over even by a couple of days brings a risk of repeatable slips and in the result disturbances in methodology you use. However, the issue is manageable and it’s the role of the leader to avoid that.

  7. In my experience timeboxing (as any other good practices: sport, diet, etc.) follows the simple rule: “who wants to do it finds a way, who doesn’t want finds an excuse” (I think it’s attributed to John Lennon, but not sure). I think the only honest (but m.b. impolite, that’s the problem) answer to your student could be: “timeboxing is one of the best practices. Do not question it until you try it seriously.” Period. It’s just too tempting to compromise any rule and any practice. There are always reasons and circumstances, but if one wants to follow a certain practice, one just has to follow it and to be conscious when (s)he starts looking for excuses.
    How could we deliver this message to our students without offending them?

  8. I have used timeboxing as a planning and execution tool in systems and software development for over 20 years with multiple successful (and to be truthful, unsuccessful) projects during that timeframe. So my commentary is based on real experience and results, not just pontification.
    The first statement I would make in this discussion is that timeboxing is just one of the many tools an experienced software development manager has available for use. Just as you would not select a carpenter for your house that only owned 1 hammer, a n experienced SW development manager does not come to the table with just one tool. This may be a fundamental difference in how others in this discussion look at timeboxing. If it is and you are one who believes in the single methodology only concept, then you need read no further because the remainder of the discussion may not apply to your selected paradigm. If, however, you believe that there is room in your development framework for flexibility in selection and more importantly application of varied tools and techniques, then you may want to read on.
    This is a very interesting discussion and has also occurred quite frequently in our organization. The discussion presented in this forum is confusing because it seems to champion “flexibility” but also seems to advocate “dogma”. For example, the question is asked about ending the iteration on a 2 week duration, artifically imposed, planning deadline. The author’s response was to end the iteration simply because it had reached an estimated completion date. That response is very “dogmatic”-an iteration is 2 weeks, period. Where is the flexibility? It isn’t in being able to deliver the functions estimated for the iteration, because they are not all done. Maybe the flexibility is in allowing the developers to project the illusion of completion without really being completed? If this is the case, could I also not do anything for 2 weeks, deliver nothing, push everything into the next iteration, and then claim progress because I “completed” an iteration? But not to worry, I am agile and flexible so I have another iteration now planned to catch the stuff I didn’t do before. This really doesn’t sound like management, it sounds like an excuse. I apologize for possibly being too blunt, but I have never been know to be a statesman.
    I believe that some of the confusion in these discussions revolve around the term “iteration”. We use RUP in our shop and while it claims to be compatible with and supports the Agile methodology, it is not specifically the Agile methodology. A discussion of the planning concepts for iterations in RUP is found at http://ootips.org/rup.html#links. There it describes “the essence of iteration is that each iteration ends in a deliverable — preferably one that executes” and later in the discussion “Again, the essence of RUP is iteration, and the essence of iteration is the production of executable deliverables.” So the focus of the iteration is the deliverable of the iteration, not the completion of a set number of days. Because of this focus, it allows flexibility to adjust the “estimated” timebox to meet the real world “execution” requirements. This should not be considered “carte blanche” to continue to delay and should never be construed to advocate sound management and control disciplines.
    This is further reinforced in the discussion at that url as it describes the planning aspects for a project using iterations “The project plan is pretty straightforward. It contains a list of proposed iterations (which all parties agree is likely to change). Each proposed iteration has an estimate (which all parties agree are likely to change). The proposed iterations are not assigned dates. Rather decision points are identified. For example:
    -by week 6, if iteration 1 and 2 are not complete, then hire one additional person.
    -by week 10, if iterations 1-4 have not been accepted by the customer, then remove iteration 8 from the release.
    -by week 15, if iterations 1-4 have not been accepted by the customer, then cancel the project.
    A project plan is not a statement of what will be. Rather it is a statement of how risks will be managed. It is a plan of contingencies, as opposed to purely a plan of action.”
    Again, all of this describes the concepts used for planning and managing the risks which in turn provide the flexibility that the author seems to advocate. What it does not do is delineate a framework that forces everyone to claim completion at the end of each 2 weeks. I wholeheartedly agree with the author that the lessons learned must be used to improve the estimation and definition of the follow-on iterations. If used in this manner, then the development maturity of the shop increases and can improve their initital estimates and therefore their planning schedules.
    I am interested in some of the comments in this discussion thread and wonder how many are developersprogrammers (whose primary responsibility is developing or coding) and how many are managers (whose primary responsibility is to ensure the whole project is successful and more importantly profitable). I ask this because of some of the more interesting statements about the management of efforts such as:
    –“know ASAP that a feature will not be finished in the timebox, and start the negotiations with the “client” – hmm, I wonder how they will feel about paying the bill for a partial delivery?
    –“We should expect to fail to meet our original objectives in some iterations.” – knowing that everything will not go exactly according to plan and preaparing contingencies for that and expecting failure are two separate things. The first forces you to be flexible, the second just sets up a self-fulling condition with a pre-made excuse.
    –“agree that failure to achieve features done in the timeboxed Iteration is expected” – same as above
    I think the discussion posts by Mr. Cauvin and Mr. Brodzinski hone in on the overall issue. A methodology will never replace the need for discipline, flexibility, good managment, and solid leadership. For those using the RUP, I would suggest that we continue to use the more flexible framework for iterations espoused by Rational and not lock ourselves into the more dogmatic approach of only 2-week cycles.
    As a logic question, isn’t it also logical that if the 2-week timeframe is so important that we absolutely do not exceed it, that the reverse would also be true – if we finish early, we should logically stretch the iteration to meet the 2-week milestone? Just food for thought, not an advocated position.

  9. For me, timeboxing is a feedback mechanism that helps in the recognition and mastery of constraints we face in developing software. When imposed with a time limit, we tend to rely on the more intuitive, subconscious parts of our brain. This is why it is important to my personal software development process. By definition timeboxing is dogmatic; the dates are not flexible but the deliverables are, and we are forced to make quick decisions under this constaint (and I’m not talking about time pressure to get stuff done under unreasonable deadlines). Through trial and error over mutliple iterations, I strive to hone in on a standard of measurement, and at the same time experience some benificial “right-brain” side effects. Finally, if I am asked by my manager to supply a time estimate for a software tasks, I cannot think of a better measurement stick than my collective history of timebox iterations. Whether this technique is used at the management level or not, it adds considerable value in my repertoire of techniques.

  10. My recommendation is to end the iteration on time.
    The way my team work is that we commit to a number of stories for an iteration and then also accept a number of bonus stories. Since estimation is inexact science this protects us from having just a little bit left in an iteration.
    When you have uncompleted work at the end of the iteration, you look to see if there is a way to make the story smaller while still delivering value. The uncompleted task becomes a candidate for work in the next iteration. This should not come as a surprise as challenges to completing this bit of work on time should have been identified during the daily stand up meetings.
    However I do not think that shortening the length of an iteration from 2 weeks to 1 weeks (or from 4 weeks to 2 weeks) will change the need for the group to work through how to schedule work to an iteration so that they can deliver what the sign up to do.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.