How an Agile or a DevOps team operates is largely defined by those working within the team. They typically develop working agreements and team charters to ensure that all members of the team are comfortable in their working environment and are aware of what they are working to build. The way in which the team interacts can be defined when the team forms, but it should also evolve and adapt to become more effective over time. Such is the purpose of using the ritual of the Retrospective within Agile methodology.

At CenturyLink Cloud, we utilize different tactical approaches regarding how we perform the various ceremonies within the assorted feature teams. However, the end goal is the same. Aim to create automated, programmable, self-service features that are of the highest quality, all while providing a delightful customer experience. Story grooming is one of the practices in which our Load Balancer team has found a nice rhythm.

As a team, we’ve found that not much beats a well-groomed story when you’re talking about creating team velocity. In this post, we talk about how one team grew into Continuous Planning over a few months, and how our team and product benefited as a result of this progression.

Evolution

When we initially formed the Load Balancer team in the spring of this year, we defaulted to using the typical approach to creating and grooming the backlog through the Product Owner (PO). Initially, the PO was almost always responsible for writing and grooming all of the stories. While this approach was functional, it was clear that there were a multitude of opportunities to operate more efficiently.

From there, we moved to a "Three Amigos" type of approach where the Product Owner would still create the stories and groom them initially. Then the product owner would consult an engineering lead on the team for further dialogue and a deeper technical understanding of how to approach the story before we planned that work with the rest of the team.

Over a relatively brief period of time, we subtly migrated to more of a full team-based approach for this discussion. In short order, we saw the distinct value in such a discussion with the whole team as long as we could control the focus and use this exercise to further develop a shared consciousness and direction of the team vision.

Now we groom stories on a daily basis with the whole team. Had I heard about this 3 years ago, I wouldn’t have allowed it! I couldn’t help but assume that this approach would have wasted too much time across too many valuable resources. Through data-driven analysis of our productivity, we have found that we actually produce more, higher quality work in less time with this approach. Our team techniques that resulted in this outcome are identified below.

Team Techniques – Daily Grooming is Always a Good Idea

agile-doodle

For starters, we found that using the given, when, then formula to best define our acceptance criteria worked well for our team. We set that as the baseline expectation that each story had to have before we brought it to the team, and we only got better from there.

As mentioned, we started to include the whole team in the discussion. When we did that, however, we added more opinions and much more discussion. So, while we greatly appreciated the benefits of the full team having a very solid perspective on what we were building, how we were approaching each piece of the puzzle, and how each puzzle piece effected the whole picture, we were forced to find a way to control that dialogue to be certain that we weren’t wasting more time than needed. As such, we started to focus on ensuring that we had time-boxed activities to control the discussion.

We added another tool for our team members to use when the conversation started to stray from the specific story in question. The team decided that we could call “squirrel” when the discussion needed to be refocused to address the story at hand and the task within it directly. We use this technique to center our discussion in situations when we’re going too deeply into actually solving the technical design of the story, or when we start to discuss follow-on work that might occur after the story that we’re grooming is completed. While calling "squirrel" may sound a little silly, it has certainly helped our team to keep the planning and grooming conversation collectively focused and productive. Any tangential discussions can be held after the immediate need is addressed which keeps us moving through grooming a single story at a time.

Daily grooming has several opportunities to add value to our grooming and planning practices. It certainly helps to spread out the planning and grooming ceremonies over a series of shorter sessions. That helps our team to avoid burning out from a long grooming session as we prep for a new iteration. It also creates a forum for our team to identify and to discuss new items on the backlog that the Product Owner has only recently added. This helps the whole team to be constantly aware of the work that’s coming and to stay tightly aligned with what we are building. Finally, daily planning gives the team a continuous opportunity to look at stories multiple times. We still review all cards with each iteration to ensure that we have the most current information and thought processes.

Continuous Planning

We haven’t totally forgotten our discipline from where we started. We still perform all of the typical Agile rituals during each iteration, but the results of our evolution allow us to be very efficient with those practices. Every four iterations or so we still have a longer planning session due to new information or a subtle change in plans, but we use the time very effectively even when the discussion needs to run longer.

We continue to time-box our grooming and planning sessions after each iteration, and we eventually evolved into grooming slightly more work each day. We further advanced into grooming and then estimating a small amount each day. Eventually, we had come so far in our common understanding of how to approach the work and what the relative sizing would be that we didn’t have a need for an iteration commitment, as we had organically grown into a continuous planning cycle.

In our journey towards continuous planning, we achieved several objectives that contributed to the power of our team. We wanted the team velocity to get faster and more consistent over time. The team got tighter as a unit; thinking more as a group rather than as individuals. Our stories got better, both from the product owner and then in terms of how effectively they were groomed. Most importantly, the vision continues to get clearer to all members of the team in order to give each team member the greatest opportunity to offer their best contributions.