The meeting started with a bit of small talk, then we settled into the agenda.

“I see that the next high-priority item is ‘Migrate to new data store’. How do we want to approach this item?” I asked.

I had just begun to work with the development team at a 70-person professional services firm in the translation space, and they had been unable to deliver much of anything for the past several months. The founder had shared with me that the team was losing the confidence of the organization and the situation was dire.

The team leader, a senior engineer, spoke up. “That’ll probably take two weeks. We can put it on the next sprint.”

“Before we do that,” I said, “what do we think the basic pieces of this project are?”

His reply was brisk. “I don’t know, but it shouldn’t take more than two weeks.”

I paused. “How long did we think the last project was going to take?”

This time there was a long silence. A junior developer piped up, “Two weeks.”

“And how long did it actually take?” I asked. I already knew the answer.

The junior developer replied, “We worked on it for over five weeks and then we had to switch to something else. It’s on hold right now.”

“The rest of the organization needs us to be able to deliver when we say we will,” I said. “It’s really challenging to do that if we’re not sure of the scope of the work. We haven’t been very accurate in the past, so now we need to do something different. We are going to work on grooming tickets in more detail so we can make better estimates and deliver on time.”

All but the most disciplined developers – even those with decades of experience – prefer coding to planning, and when given the chance, they will jump right into coding a feature. They assume that they comprehend it well enough to deliver, but the more complex the feature, the less likely they are to be correct, and the more likely they are to blow their delivery estimate clear out of the water.

Many teams start working on projects that they haven’t carefully thought through, quickly stumble upon unexpected complexity, and the project rapidly increases in scope and drags on until the plug is pulled because other projects are piling up. Then the costly cycle begins all over again, only the next project is behind from the start because of previous overruns. The team soon finds themselves hopelessly mired and unable to complete anything.

Much of this mess can be avoided if the team spends time working through projects in a process called grooming. To groom effectively, your team must have a few pieces in place: sprints, standups, and planning meetings.

Sprints are regular work cycles with hard start and end dates, and are used to quickly deliver value in small, manageable pieces. Standups are frequent (3-5x/week), brief meetings for synching up the team, and planning meetings are used to lay out the work that will be done for the next sprint. Grooming can be performed by the team in an hour or two of meetings over the course of a two-week sprint. There are other highly useful rituals and artifacts that can drive an effective and efficient development process, but those are beyond the scope of this post.

Before we dig into the details of grooming and finding the right balance for your team, we should touch on one concept first: Just in Time, or JIT.

JIT is a critical part of any agile process. Let’s assume you have 500 items in your backlog, and you decide to prioritize, refine, and estimate all 500 all at once. That’s a considerable amount of work. In fact, it’s likely that before you finish, many of the items will become out-of-date or business goals will change, rendering a large part of your work obsolete.

The above technique- performing all of one stage of the development process before moving on to the next without returning to any previous steps – is known as the “waterfall” methodology. Waterfall was the predominant mode of software development until the early 2000’s, and while it can still be effective in limited situations, agile techniques have proven vastly more effective in many other use cases.

In an agile process, we do just enough work at each step to deliver value, but not so much that we risk wasting effort. We also frequently return to previous steps to make refinements based on new information. For example, we might identify a few high-priority items in the backlog that we are certain we will tackle in the next couple of sprints, add some detail to them, and make a rough, back-of-a-napkin estimate of the effort required to complete them.

Then, as we become more certain that we’re going to include the items an upcoming sprint, we use subsequent grooming sessions to revise them further, adding even more detail by doing deep dives into technical issues and perhaps breaking items into smaller tasks, and making ever more precise estimates of effort.

By the time we are ready to plan the sprint, we have a sufficient number of high-priority backlog items, groomed in just enough detail, with close enough estimates to work on. When we are finished planning the sprint, any remaining groomed backlog items may end up being waste, because it’s possible we will never get to them.

To groom like Goldilocks, “not too little, not too much, but just right” will take practice. If you are planning sprints and running out of groomed backlog items, add more time to your grooming schedule. If instead you have a significant number of well-groomed backlog items lying around after your sprint is planned, then decrease grooming time.

As you get comfortable running sprints, a good tool like Jira or Linear will quickly give you a sense of the team’s velocity, or the average amount of work they can complete per sprint. For example, if you use points to estimate effort, you might find that your team’s sustainable velocity is around 40 points. You can then use 40 points as your target volume for sprint planning, which then will dictate how much backlog grooming you should be doing.

Teams that jump right into coding for anything but the simplest of features are playing with fire. Not “Isn’t that adorable, they’re lighting matches” playing with fire. No, we’re talking about a bonfire fed with heaping stacks of your business’s much-needed capital.

Don’t get burned. Accustom your team to regularly grooming backlog items in detail and adjust as you go to determine just the right amount for your needs.