Commitment to Sprint Delivery vs Time-boxing
Commitment to Sprint Delivery vs Time-boxing
[From the Archive: Originally posted at Amplify.com May 1, 2010]
This post is my amplification of a point being discussed on Twitter the other day.
Context
The thread of discussion was kicked-off by my response to this tweet: “with time-boxed iterations, you commit to implementing all [stories] within a given period of time”
My initial response was: “No, not commit, just select”
Some folks seem to have taken exception to this (and probably with some cause, given its brevity), so here’s a little more of my perspective on twin subjects which are close to my heart, and receives less attention than perhaps they warrant: Commitment, and time-boxing.
Note: The subject of time-boxing mostly applies to agile approaches with fixed-length iterations, such as Scrum, although I would suggest that there is merit in considering time-boxing for e.g. individual cards / tasks / deliverables in Kanban, also.
Time-boxing
For me, timeboxing means setting a fixed end-date (for e.g. an iteration), and not ever allowing work to overrun that date. Not contentious so far, I hope.
Given a fixed end-date, then, the question must sometimes arise as to what happens when that date is reached and not everything planned for delivery on that date is “feature-complete”. I have generally thought it best to anticipate this situation, and have a project management pattern named “Constant State of Ship”. This pattern proposes that work items within a sprint should ALWAYS be “shippable” (at, say, 10 mins notice, max), at every point in their evolution, from “not started” to “feature-complete”.
Wikipedia says (of time-boxing): “If the team exceeds the date, the work is considered a failure and is cancelled or rescheduled”. I prefer to say “All work is shipped at the end of the timebox, some of it may not be feature-complete”.
Put another way, a time-box, for me, means allocating a fixed amount of time to work on a thing, and shipping that thing as soon as time is up.
Aside: In the past, I have worked with some project teams where we timeboxed the individual tasks / work-items / deliverables on the sprint plan, not just the sprint as a whole.
Commitment to Delivery
Given the above take on timeboxing, hopefully my comment on commitment takes on a little more clarity.
Commitment, then, involves the team as a whole asking its members to sign up to working on the planned tasks / work-items / deliverables for a fixed amount of time per item.
Aside: To improve the chances of that fixed amount of time being sufficient to reach “feature complete”, I encourage new teams, as part of sprint planning, to provide a “percentage likelihood of reaching feature-complete in the committed time”, for each item. Estimates below 80% trigger a re- evaluation of the allocated time / people, and most likely some re-planning. More mature teams can forego this step.
Summary
In summary then, time-boxing, as described above, means that teams – and individuals – don’t commit to shipping everything as “feature complete” in each sprint, but commit to doing their best to get as close to feature-complete, for each item, as they possibly can in the time they have allocated themselves.
I leave it as an exercise for the reader to consider the implications of this strategy, with regard to motivation, teamwork, and customer (product owner) satisfaction.
– Bob
Think Different