To say that we Scrum practitioners, trainers, and coaches are…ahem…obsessed with size might be one of the biggest agile truisms that exist. While some may argue it’s not an obsession, the fact remains the issue of size shows up throughout Scrum. Its importance cannot be denied.
We at 3Back maintain that size impacts how well we “do Scrum.” Rather than talk about it behind closed doors, we present you an open and honest discussion about why size matters.
In Scrum.
Find the Sweet Spot
When it comes to the size of a Scrum Team, there most definitely is a sweet spot. According to the basic rules of Scrum, that number looks like 7, plus or minus 2. In our work experience, we have found the sweet spot, otherwise known as the ideal number of people that can effectively be involved in a single conversation, to be 5. However, the reality in your organization may be different. The Team may be building a Product that requires different skill sets found amongst several Team Members or extending to SMEs, such that a team of 9 (7+2) emerges. A Team this large will bring its own big-size, self-organizing issues and the Organization will have to deal with it in its own way, perhaps by splitting Teams.
It’s All Relative
Sizing, aka estimating, Stories is a critical component to Sprint planning and forecasting, not to mention Team dynamics. The key to remember is that the goal of sizing Stories isn’t to establish a fool-proof prediction of the future. Rather, it is to gain clarity through collaboration and information as to what the PO wants. To this end, estimating Stories, is done in units of relative effort known as Story Points.
It is easy for a Team to fall into an attractive, yet dangerous trap of relating Story Points to hours or days of work. “Well, this should take around 20 hours, and we think a point takes around 2 hours, so that’s a 10 point Story.” Why is this tempting tactic a problem? Because Story Points allow Team Members who work at different rates to communicate, learn from each other and forecast more effectively. For example, two Devs may agree that a given Story is two Points, even if their individual estimates of actual time to complete the task are quite different. Beginning with the agreed upon estimate, and then the Devs can estimate another Story as four points if they agree it will take twice as much effort as the first Story. If Story Points are only denoting hours, then the benefits of estimating as a tool to gain clarity are gone.
The Importance of Grooming
Sometimes the Backlog can get a little too large and unkempt. That’s when it’s up to the PO to collaborate with the Team on Backlog Refinement (Grooming). Backlog Refinement includes moving Stories from the Fridge, Freezer or InBox into the Back Burner and further refining them until they are Ready to go to Planning. But first, the PO with the help of the Team needs to determine if the Item’s size denotes a Story or an Epic. It the Item is already ‘small’ enough to be a Story, it is moved to the Back Burner directly for further refinement. If the Item is larger and is an Epic, Stories must be extracted from it and moved to the Back Burner. In either case, the Stories now in the Back Burner are examined and rewritten if necessary so that their goals are simple, clear and correct. Now, the Stories are ready to be pulled from the Back Burner for Planning.
In Scrum, there’s no denying. Size, indeed, does matter.
Want to know how your Team sizes up with Scrum?
We’ve got training and coaching for that.
As Always, Stay Agile.