Breaking the Cycle of Over Committing
This blog was co-written by Softrams' Agile Community of Practice Lead Marcele Viana and Senior Scrum Master Jim Garner.
When an Agile Scrum team is doing development work for a client who is still in a waterfall-time-based cadence (or locked release dates), many teams will end up falling into the anti-pattern of over committing to adapt and compensate.
The biggest symptom of the over committing anti-pattern is that during Sprint Planning, teams will skim over the details of all of the sprint candidate work items and commit to most (or all) of them. Not truly considering if they can complete them all or not, and not considering their capacity because they don’t feel like they can say no. We see this a lot in teams where they get the pressure of “we’ve promised”, “the client is expecting”, or some other form of deadline-based expectation.
However it happens, over committing can quickly become normalized and the team members oftentimes accept it. Then, as you would expect, this results in having work left at the end of the sprint (unfinished or not even started), which then will start to snowball into an ever-growing list of work rolling over from one sprint to the next.
The cycle repeats: Over Commit > Roll Over > Over Commit > Roll Over > Etc. To the client, this cycle creates the illusion that the Scrum team cannot be relied upon to deliver. Subsequently, the Scrum team has no vested interest in what is “committed” work each sprint.
So how do we break this cycle and still deliver to a client who has deadlines?
First and foremost, the Product Owner, Product Manager, or whomever is working with the client needs to be transparent with the client on how iterative development works, and make sure the Scrum team understands upcoming deadlines.
Then, we recommend that the Scrum team limits their planning overage to occurring 20% (or less) of the time. Occasionally over committing can help the team build their confidence and show the client that the team is pushing themselves to increase their velocity. Where the 80% regular commitment provides the much-needed predictability, by remaining realistic most of the time, with the estimations and completion of the work “as committed”.
Using techniques like identifying work as “stretch objective” but not committing to it will help the team to grow and allow them to feel successful. Negotiating with the client on a realistic minimum marketable product, based on their deadline, will help set expectations.
The goal should always be to keep the Scrum Team’s sprints a balance of flexibility and reliability. Constantly over committing to work doesn’t mean that the team will get any more work done. It only means the team will feel like they’ve failed most of the time and they will stop being invested in succeeding at sprint commitments.
