Better Estimates with Empathy for the Scrum Boundaries
What are Bumper Cars?
“Bumper cars or dodgems is the generic name for a type of flat ride consisting of several small electrically powered cars which draw power from the floor and/or ceiling, and which are turned on and off remotely by an operator. They are also known as bumping cars, dodging cars and dashing cars.” – Wikipedia
A Bumper car runs with an average speed of 5 miles per hour. When Bumper cars collide, the drivers feel a change in their motion and become aware of the inertia it creates as experience. This may stop the cars or change direction but definitely leaving the driver safe to continue with this experience of driving the Bumper car as the individual was before.
It is the cushioned barrier forming the edge of the rink and the protective barriers around the cars provide enough safety. In short, the well-laid boundaries create safety and allow the individual to continue enjoying the driving experience.
Scrum Team & the Right Boundaries
Similar to the cushioned barriers creating safe boundaries in Bumper cars, Scrum too has boundaries part of the framework. The very first place we experience one such boundary is with time-boxes. The Sprint is a boundary that helps in reducing risk by not continuing to deliver the desired value beyond the length of the Sprint with frequent Inspection and adaptation. Hence many organizations prefer shorter Sprints in order to reduce the risk and cost of delaying feedback.
Further, the boundaries do show up when the Scrum Team tries to gain clarity on what decisions are made by whom within the Scrum accountabilities.
Forecasting a Product Backlog Item for when it will be done is a decision made as an outcome of the Developers’ shared understanding of why what and how things might get done to realize value. Without any doubt, clarity on the boundaries and how constrained the boundaries to drive a remarkable difference in coming up with forecasts.
Empathy for the Right Boundaries
Tackling with Boundaries is not so na?ve that you can bring a RACI matrix and sort it out with. Empathy on what boundaries are and how they get influenced by constraints is highly essential.
Remember the analogy of learning how to skate on a dry concrete floor with a pair of skating shoes. Your earlier lessons to understand the movement and how to get balance with a pair of shoes fitted with wheels are highly constrained. In fact, at one point in time, you might feel like walking with a regular pair of sneakers. But as you start practicing and learn the art behind skating, the wheels are relaxed allowing movement. It is definitely scary and tricky, but you have to face it to get better at it.
How are your Developers part of your Scrum Team doing today? Are they too constrained with all the wheels locked when they are about to forecast when things will be done? Or are they left too loose with no clarity and purpose but expecting them to skate through well delivering value somehow?
When the Developers are too constrained while providing estimates, they are missing out on the purpose of shared understanding and how creatively to look at solving customer problems ( which involves having a definite space to learn and experiment).
At the same time when the same Developers are left with absolutely no constraints while providing estimates, they get too divergent and drive conversations in a chaotic fashion lacking collaboration (which delays building team cohesion and gaining confidence to solve customer problem)
Neither of these extremes is a wise thing to embrace in a teams’ construct.
“Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage” – 37 Signals
How to overcome this situation?
- Have a clear Vision and associated Product Goals (outcome driven).
- Communicate and clarify on Vision and the Product Goal often.
- Facilitate the road ahead seeking estimates bringing a strong reference for PBIs with the Product Goal.
- Understand the estimates for Product Backlog Items are forecasted only by Developers and every other role is only either consulted or informed and not responsible or accountable for.
- Leverage Scrum Events for continuous adaptation in turn continuously improving the way Developers self-manage to provide estimates.
Wrap Up!
The key to finding the right boundaries is more of an art than a science. Scrum time-boxes and feedback loops can turn out to be advantageous when constrained for Developers in providing estimates.
Remember straying outside the protected area more often delays the Developers’ from collectively maturing in making estimates. Enjoy wisely with the cushioned barriers coming in terms of empathy to boundaries (in terms of context, purpose, and clarity on accountabilities).