“Adequately Groomed”
Grooming presents opportunities and challenges in successful Agile product development
I was indoctrinated early in the Agile movement, during a time that the methodology was not yet so universally adopted and today’s many tools didn’t yet exist. This was a time of index cards tacked to bulletin boards, around which teams actually stood for daily Stand-Ups. Our Agile was highly practical, but more provincial than the mature iterations utilized by globally distributed teams today.
In that early form of Agile, grooming played a comparably minor role. Our Agility revolved around a backlog with functionality defined in only the most skeletal fashion. While we all knew there were unknown challenges and constraints hidden in that backlog, we accepted associated downstream refactoring as a cost for moving as swiftly as our methodology allowed. We operated methodically, introducing user stories into the sprint planning process in stripped-down form, and embraced that part of the job would be to significantly expand associated requirements during the run of the sprint. The goal was to yank the story from the theoretical to the practical as quickly as possible, trading detailed specifications for iterative prototyping.
Oldschool Grooming
Among the many things I learned along the way from kick-ass technologists like John Reynolds and Ira Tau was the opportunity that a richer grooming function provides for developers to begin incubating upcoming solutions. “[To walk into sprint planning stone-cold and maximize our inputs is really difficult,” they explained to me. “[We’d much rather have a decent idea of what’s over the next hill so we can be noodling it ahead of time in the background of our current work.]”
“[We’d much rather have a decent idea of what’s over the next hill so we can be noodling it ahead of time in the background of our current work.]”
Our negotiated solution was to engage in grooming via a 60 or 90-minute session, no more than halfway through the current sprint. Over time, we learned that this approach struck a balance between the benefits to all team resources of ‘peering over the next hill’, without dragging too much focus away from the work promised during the current sprint.
Among our key tenets was shared agreement that simply because something was discussed during grooming did not guarantee that it would find its way into the next sprint planning session. Agile pivots on providing Product Owners maximum freedom to prioritize the backlog in real-time. The handful of days between grooming and the next sprint planning session sometimes brings plenty of change in the business context to justify shuffling the backlog to match. Our product development process demands the flexibility to match those swings.
The Spike
With solutions that were particularly complex, or involved the integration of functionality across multiple platforms, this approach sometimes came up short. While rapid prototyping is always a benefit, maximizing the volume of vetted requirements within each prototype version helps to compress the total time between concept and productionalization. Based on this reality, some teams chose to invest more time on the theory part, prior to initializing prototyping.
Maximizing the volume of vetted requirements within each prototype version helps to compress the total time between concept and productionalization
One way we attacked this compression, while maintaining the integrity of the underlying Agile opportunity cost economy, was via the spike. A spike is a special breed of user story, focused on the generation of some value other than working functionality. Many teams utilize spikes to ‘groom ahead’ when necessary, defining the details of a feature ahead of code ever being written. An important best practice with spikes is that, just like all other user stories, each is defined by a specific deliverable that can be demonstrated to the team during the sprint review. For a Spike, this deliverable often takes the form of actionable documentation.
Spiking trades a measure of the just-in-time nature of Agile development, but does so in a manner that is well-governed. While we are thinking more distantly ahead, we have adequate control to manage the spiking effort within the economy of the current sprint.
“Adequately Groomed”
Fast forward a bunch of years, to a client engagement of my own around a transformational supply chain management program in the pharmaceutical industry. This program was highly complex, involving dozens of groups from across Technology, Operations, and Change Management, as well as several key external partnerships. That team faced many challenges along the way, the most dramatic of which was generating a robust enough supply of “adequately groomed” user stories to feed the beast of our Agile velocity. A high-class challenge, to be sure, but an impediment to progress nonetheless.
Generating a robust enough supply of “adequately groomed” user stories to feed the beast of our Agile velocity
Based on the unique constraints of that initiative, prototyping our way from zero to working features was deemed inefficient. The team needed to develop additional techniques to meet this demand. The head of our Quality Assurance and Business Analysis team, Asheesh Sengar, was key in helping to define and organize these solutions.
Grooming Squad
One strategy, utilized effectively throughout the program, was instantiation of a sub-team we called the “Grooming Squad”, introduced by Doug Mandart. This group — all members of our dedicated Agile workstream — ran its own parallel process to define and document upcoming user stories, out ahead of the main body of the team.
A few challenges with this approach:
- Striking a balance between engagement of resources in the Grooming Squad and fulfilling promises in the current sprint was a continual challenge. As this process evolved, the two groups became more practically separate, such that promised sprint work was not normally assigned to the members of the Grooming Squad. Ultimately, Grooming Squad became the domain of our Business Analysts and Tech Lead, while the Developers and Testing Engineers focused on the current sprint. Scrum Master and Product Owner swung between the two.
- Among the most powerful benefits of Agile is its insistence that ALL team resources participate in all phases of the build. Fifteen years of Agile success has proven that this approach delivers positive ROI in terms of speed, quality, and cohesion of the features under construction. A danger of the Grooming Squad is that it lifts the more theoretical parts of the process out of the core team. What we definitely don’t want to do is separate into two disparate teams: one that does the thinking work and another charged with execution. Once we allow that to happen, half the benefits of Agile drain right out the bottom of the process… In this instance, this risk was mitigated through strong communications and coordination between the core team and the Grooming Squad, as well as devotion to that weekly, all-hands grooming session wherein the entire team solutioneered together.
Maximizing the Spike
Another successful strategy, driven in this program by Lisa Wentworth, came through maximizing usage of the spike. As discussed previously, the beauty of the spike is that it fits right in with the existing economy of the sprint. If completion of a spike requires 30 hours of work [this team utilized working hours as its key unit of effort] from one resource, those would be 30 hours unavailable for allocation against any other work. Including development work.
As this team’s process matured, spiking became as prominent as part of each sprint as development, itself. Velocity in dev certainly took a hit as a result, but that was deemed necessary in order to reach the “adequately groomed” threshold this team was shooting for.
Practically speaking, this created a cadence wherein user stories were spiked in one sprint and developed in the next. Further, due to the idiosyncrasies of this specific environment, it was difficult for the Testing Engineers to complete all testing and secure Product Owner signoff within the bounds of a single sprint. Thus, the testing of many User Stories occurred in a following sprint, as well. The diagram below shows how this cadence manifested for the majority of user stories:
This might not be the best approach for your own team within your own environment, but it worked well for this team in theirs.
Conclusion
My father, a trade machinist and kick-ass carpenter, likes to say, “It’s all in the prep”. His point: if you focus adequately on preparation, execution is much more likely to go smoothly. That philosophy certainly holds true where product development is concerned, and Agile challenges us to strike a critical balance between preparation and execution in the service of speed to market. One important way that preparation manifests itself in this context is through the grooming of user stories to be executed in the future. Some environments and problem sets allow for a light-touch where grooming is concerned, compressing the time between concept and Production. In other circumstances, getting to “adequately groomed” requires more robust investment of time, effort, and creativity. Regardless of the attributes of your own environment, Agile provides the tools to recognize these challenges and overcome them.
