Time-boxing User Stories

Recently I’ve started to think about the concept of time-boxing for user stories.  In Scrum, most things are, can, or should be time-boxed: sprints, releases, planning sessions.  Providing a time  constraint has demonstrated value: it limits the scope of effort, it can curb expensive and unnecessary perfectionist tendencies, it eliminates waste, and it forces prioritization.

One thing that Scrum doesn’t promote is time-boxing of user stories.  We know that user stories are designed to place-holders for future conversations — in other words they aren’t complete and detailed requirements.  We also know that user stories are supposed to be estimated, and that estimates aren’t commitments (well, we should know that). So why does Scrum provide for time restrictions at a higher level, but not at the user story or task level?  I think I answered my own question: the level detail a user story would have to contain wouldn’t support an agile approach to development, and it would mean estimates aren’t estimates but instead are commitments, which we’ve learned is unrealistic in software development.  But I think there’s room to maneuver.

Specifically, in user stories which are complex or involve high technical risk, or in other words user stories that have a good chance of taking way longer than we thought, it can make sense to time box the story, or even the tasks within the story.  I’ve recently asked my team to try this — specifically as a response to ‘technical’ stories which have spun out of control.

Some ideas I’ve floated on how to approach this:

1. Pick a level of effort to commit to on a story; this should be done in consultation with Product Owner (PO) and ScrumMaster (SM).
2. Breakdown the time you need to spend on each task; if this is way beyond the original estimate of the story, have a conversation with the SM and PO.
3. Consider using the Pomodoro Technique to track your time (e.g. if you have given yourself two hours to work on a task, that represents four pomodoro sessions). This will make it easier to not let time get away on you.
4. Just as we prioritize stories in a sprint, prioritize the tasks and acceptance criteria in the story (with either the PO, SM, or architect if it’s a technical story).

Smells:

1. If your acceptance criteria is unclear, this is an indication that a conversation is needed. You should never undertake a story with unclear acceptance criteria — but this is especially true for time-boxed stories.
2. Track your actual effort against tasks and the story and raise the alarm if it looks like the story is out of control.

The final word on this is to use it with caution.  We usually cover around 15 stories in a sprint.  Time-boxing more than one or two is probably an indication that there are bigger problems.