An interesting discussion that frequently crops up when introducing Scrum to certain organizations and individuals is the argument that they don’t have time for backlog grooming because they have “work” to do. I get this argument a lot during coaching engagements when I tell team members they need to spend five percent of their time grooming the backlog. After all, that amounts to two hours a week for a full-time developer. Wouldn’t that time be better spent, she asks, writing code?
The fundamental problem I think is what we consider “work.” Software developers and their managers tend to assume that any time not spent coding constitutes time not working. “I’m a software developer. I’m paid to write code. I’m not paid to sit in a meeting, looking at a bunch of user stories that aren’t ready for development yet.” Very often this attitude is reinforced by the organization. “We can’t afford to lose X hours of developer time while they sit in a meeting when we really need them working.” In fact, I actually had one senior manager say to me regarding a team, “They need to spend less time talking about the software and more time writing it.”
A fundamental shift in mindset is required. Scrum has very few moving parts (three roles, four meetings and a small number of artifacts). Each one is there because it has been shown through empirical observation to be a high value component of agile development. This is not some theoretical framework that some ivory tower types came up with in a vacuum. Rather, this is STUFF THAT WORKS. Not only that, but things like regular, diligent backlog grooming ARE THE WORK (or part of it) required to do software development well (if you prefer to do software development badly or aspire to mediocrity, read no further).
The CSM course I teach includes a large simulation component wherein course participants actually do Scrum (albeit in an abbreviated, simulated way). In nearly every course, one or more of the teams of participants identify having a well groomed backlog (i.e. a set of well-defined, thought-out user stories with robust acceptance criteria) as the essential ingredient to the success of the sprint. They recognize, as anyone who approaches backlog grooming with discipline and rigor does, that a well defined backlog (at least well defined for the top 20 percent or so) eliminates confusion, false starts, and rework later. After all, a backlog is really nothing more than a bunch of placeholders for work that needs to be done or, as one agile proponent put it, a user story is “…a promise for a future conversation.” Some of that conversation occurs in the grooming meetings.
This is not really news, nor even special to agile development. We have known for decades that if you think about what you’re going to do before you do it, you will do it better and faster. The bottom line is you can do a bit of work now, while carefully considering what you’re going to do next, or you can jump in and do it and then spend more time later fixing everything you did wrong. It’s better (and cheaper) to correct mistakes in your head than to correct mistakes in reality.
As a parting thought, consider this: It takes an elite sprinter 9 to 11 seconds to compete in the 100 meter event in the Olympics and yet he or she spends tens of thousands of hours preparing for the event. If we want our Scrum teams to be elite “Sprinters,” we need to give them adequate time to prepare and they need to recognize how essential that preparation is to success. And again, we need to understand that the preparation IS THE MOST IMPORTANT WORK.
Jimi Fosdick
CST