The Nature of Time-boxing

[From the Archive: Originally posted at Amplify.com Nov 18, 2011]

Time-boxing seems like such a simple concept. A team – with their Product Owner – gives themselves a fixed period of time, say two weeks, to:

• figure out what’s the most important things to next add to their working product
• build those things
• integrate them into the working product

(Note: I’m not going to digress about the need for *working* software in this particular post. Maybe another day).

But there are some hidden dynamics at play, underneath this simple- looking veneer.

This post is about just one of those dynamics, namely, the interplay of time-boxing and commitment.

Many Scrum practitioners (and their customers even more so) have come to believe that if a Scrum Team fails to completely deliver ALL the items it has planned for a given time-box (Sprint), then it has “failed” in some way. Failed, indeed, to “meet it commitments”.

This viewpoint leads to increasingly dysfunctional behaviours, as describe recently by @yuvalyert (Yuval Yeret) in this blog post.

For all the successful development projects in which I have been involved, we have always treated time-boxing as a means to curtail overruns of effort, especially with respect to individual items (deliverables). That is to say, during Sprint Planning the folks involved in working on a given Sprint deliverable (for example, a User Story) agree amongst themselves – and with the rest of the team – on how long they will spend on that item (Note: NOT how long they expect to take to bring that item to some kind of completion, or state-of-readiness. I.E NOT an “estimate”). So, the Team commits to spending some finite amount of time on the item, NOT to completing it. We have found this distinction to be crucial.

We also apply this same perspective to the Sprint as a whole. We commit to spending two weeks (no more, no less) of our collective best efforts on working towards the Sprint Goal. We do NOT commit to delivering specific things in a fully-finished state. (Aside: It’s kind of important that everyone – Team, Product Owner, stakeholders, management, customers, etc. – all understand this clearly, with regular reminders).

Of course, if during the Sprint it begins to look like some items will not be completed in their allotted (mini) time-boxes, then the Team, the Product Owner (and maybe other stakeholders too) can have a discussion about what to do. This, for me, is one key aspect of being Agile (correcting course as necessary, even whilst “in flight”).

This does mean that some Sprints will deliver less (integrate less functionality into the working product) than expected. And some will deliver more than expected. Swings and roundabouts :).

This is the nature of software development.

– Bob