The Bench

Have you ever been on a project where business requirements were written so far in advance that they were obsolete before development had even been started? On the flip side, have you ever had a rock star developer scrounging for odds and ends part-way through an iteration because they finished early but there were no more development-ready stories queued up for them?

Wouldn’t it be cool if business requirements could always be completed “just-in-time? Ahh yes, the optimal timing of business and development efforts! Agile gets us pretty close by advocating simplicity (maximizing work not done), iterative development, and lighter-weight requirements documentation. This results in much lower risk of wasted effort such as obsolete stories. Reality, however, is that teams experience unexpected bandwidth from time to time and require a limited stockpile of developer-ready stories to maintain maximum velocity. I refer to this cachet of developer-ready stories as The Bench.

What is the Difference Between a Bench and the Story Backlog?

Sometimes people think that if a developer finishes their work early and need something else to do, they should pull a story from the Story Backlog. However, this is not Waterfall; you haven’t completed detailed requirements for all of these stories in advance. The Story Backlog consists of placeholder stories, which are awaiting prioritization in an upcoming milestone and do not yet have detailed requirements.

As previously mentioned, you need a little buffer zone of developer-ready stories to ensure that the team always stays productive. The Bench, therefore, is the minority portion of the Story Backlog that is developer-ready.

Why a Bench?

Why can’t we just anticipate when people will be ready to move on to more work and complete the necessary business analysis just-in-time? Here are a few reasons:

1. Unforeseen Roadblocks – Sometimes an unforeseen issue or dependency halts development.
2. Early Completion – Developers have been known to find brilliant and elegant approaches that help them complete their work in a fraction of the expected time.
3. Unexpected Resources – A development resource may unexpectedly available to the team mid-iteration (back early from vacation or an unexpected addition, etc.).

You’ll want to have work ready to go so that such unexpected situations won’t adversely impact the team’s momentum and delivery velocity.

Bench Considerations

Take these into account when determining the stories for the bench:

1. Next Highest Customer Priority – First, ensure that the stories on the bench are the highest priority stories not already scheduled for the current iteration. If you do this right, these should be the stories that would have been done in the next iteration or two anyway, so they won’t just sit for months.
2. Quantity – You don’t want a massive bench that puts you at risk of obsolete stories and wasted work, but it is a good idea to have a bench of at least a week or two of developer-ready stories beyond those assigned for the current iteration.
3. Variety – Try to stock the bench with a variety of stories. If an average developer finishes early but the stories on your bench are highly complex or too far outside of their domain expertise, they may not be able to pick one of them up.

In summary, maintaining a modest bench of developer-ready stories limits the risk of obsolete business requirements while ensuring that your team stays 100% productive.