Can buzzwords and acceptance criteria help with better estimation?

How an exercise in inclusive story points lead to transparent estimation across teams.

By Jennifer Jones, CSM , Digital Product Manager at Freewheel — A Comcast Company

We’ve all done it. If you work in any sort of corporate setting, you have inevitably dipped into the pool of buzzwords and phrases that can render eyes useless as they roll deeply into the backs of your colleagues’ skulls. “Before we begin, I just want to level set with you.”, “The level of complexity is still unknown.”, “We really need to think outside the box here!” and countless other buzzy gems are often tossed around like leaves in an autumn breeze.

When it comes to Agile organizations, many would argue that the buzz list grows exponentially: “These stories need a size!”, “ We have to refine this backlog!” , “Did you add acceptance criteria to the story?”. Not to say that these words and phrases don’t hold meaning or value. They certainly do! But sometimes, if we’re honest, they can all be a bit too…annoying, ingratiating, overused.

Even still, the truth of the matter is that using these phrases tend to, wait for it, “level set” what the objectives or goals are for a particular conversation or task. If we can agree on that fact, then why not use this concept of “buzzwords” to help conquer one of the most confusingly fluid pieces in the agile process: story estimation.

From T-shirt sizes to Fibonacci, estimation is a universal pain point for agile teams.

The truth of this statement can be tested by attending any number of agile events. I can confidently say almost every single agile-focused conference, training, or meet-up I have attended over the last several years has reserved time to tackle this very topic. Most questions on the matter focus on what SMs and agile coaches can do to get teams to size based on overall effort. Most advice on the subject centers around “just getting away from estimating in days” and focusing on overall team effort. Nice little catch 22 we’ve got there!

While I agree that “overall effort > estimation in days”, coaching this skill can be difficult to successfully accomplish when teams lack familiarity around the work each other has to accomplish to deliver a story to done. As a Scrum Master, it was this issue (and many moments of frustration shared with several agile teams over the years) that motivated me to try something familiar: categorize the work with buzzwords.

Why didn’t I think of this before? Everyone knows what “minimal” means. And they certainly get the weight of that word when ranked against something categorized as “complicated”. How easy! Let’s pair up our numerical values to buzzwords so we all understand each other’s perspective on a story! Simple right? WRONG.

Buzzwords alone cannot get this done. Sure, we can all rattle off a definition for words, and most of us would agree with said definition. However, with estimation at play, we’re not talking about definition, we’re talking about context. Let’s use running as a comparison. What could be defined as an “easy” run for an athlete that has completed a marathon can be drastically different from what is seen as an “easy” run for a novice. “Easy” still means the same thing no matter how you slice it but the context shifts based on the level of expertise of your runners.

To add value to the use of buzzwords in estimation, we have to do more than define the word. We have to provide context from across the team. What does minimal mean for QA vs Engineers vs Designers? What does it mean for a new employee vs a veteran? Is there an agile process that is already encouraged and, not only defines the scope of work, but can provide context on how each story gets delivered? Why yes there is! I’ll give you 3 guesses on what it is but I’m guessing you’ll only need 1.

Acceptance criteria offers more than a “definition of done” for work. It provides context around the specific conditions needed in order for a feature to be accepted by a user.

The same rule can apply when talking about estimation. Sizing is not just defining the estimated effort based on a value. It is providing context around the collective effort needed in order for a story to be accepted by the team.

It seemed an easy choice to use acceptance criteria to help better define what our estimation buzzwords (and values) meant. If a story is described as “minimal”, what are the specific conditions — the context — needed in order for it to be defined as such from a QA perspective vs an Engineering perspective? What does “minimal” mean for a junior level employee vs a senior level employee? Acceptance criteria helped our teams to better understand the perspective of each team member when they said “minimal” or “complex” and helped to foster a sense of overall effort vs individual time spent.

So what does this look like in practice?

In the example infographic, you can see the buzzword, acceptance criteria and Fibonacci value assigned to the smallest and largest estimations. Compare the differences in AC when talking about trivial effort vs something a bit more complex. Does it have to look like this exactly? Of course not! This exercise could easily be applied to T-shirt sizing or even the use of strictly numerical sizing, a la Fibonacci. The important takeaway here is that the sizes provide context for each team member involved and what is need in order to cross the finish line. With that in mind, here are some tips and teaching moments I encountered when introducing this concept to teams:

1. Much like a Working Agreement/Team Norms exercise, this takes time. — Look, this isn’t a rocket to success on estimation. This exercise values individuals and interactions over processes and tools. It takes time for teams to readjust, to consider everyone’s perspective when talking about effort. It may also take time to break these sizes down to clear and concise criteria. One thing I would recommend, start with providing context around your largest and smallest values. Once those are clear, it becomes a bit easier to fill in the gaps on all the in between.
2. This exercise can be paired with (almost) any sizing method. — As I said above, it doesn’t have to look like the examples I provided. Dare I say, this can be a very agile exercise! Taking a queue from therapy, buzzwords and acceptance criteria are used as a “grounding” technique. They’re not here to be the end all, be all to estimation. They’re here to provide clarity and transparency around sizing. Your teams use a different estimation value? Cool! You can still give it a whirl!
3. If pairing acceptance criteria with buzzwords, let the team decide on the buzzword first. — In running this exercise a few times, one thing I’ve noticed is how much easier it can be to provide context (read: acceptance criteria) around size when teams understand to what that context is connected. Fibonacci is great but can be a bit esoteric when introducing new team members to your estimation process. T-shirt sizing can actually prove to be helpful in this exercise. If that’s not your estimation tool and you favor numbers, using words to describe effort provides teams with a visual tool. It allows teams to determine what “small” or “large”, “insignificant” or “messy” might mean to them.
4. The value is not in accuracy but in transparency. — I cannot stress this enough: the end goal of this exercise is not to drive better velocity metrics (although, I have seen cases where this exercise has provided more predictability). The end goal is to make it clear what a team means when they say something is Complex, Large, an 8 or whatever value you assign. This can be particularly helpful in enterprise companies where scaled agile principles are at play. If there are multiple teams with different areas of focus, how can someone outside the team understand what their estimation might suggest in terms of effort and delivery? Having acceptance criteria and buzzwords (we could even say “keywords”) around sizing could offer some clarity.
5. Distributed teams may find this hard to tackle at times. — Let’s be honest shall we? While agile indicates teams should all be co-located, in this day and age, that is increasingly unlikely the more global companies become. Because of that fact, sometimes it can be hard for distributed teams to grasp this concept as quickly as co-located teams. Why? One observation I’ve made is the impact exposure, or the lack thereof, to each other’s day-to-day work environments can be in informing perspective on effort. Without being directly “in the mix”, it’s hard to sometimes grasp all the daily minutiae that affects effort — lacking clarity on what all goes into the work at hand when you’re not as familiar with how processes differ between offices. What one dev might have easy access to do in the US - perhaps something like spinning up an environment- might not be true for their counterpart in the UK, thus adding more complexity to the UK team member’s effort and their perspective on estimation. Teasing out some of those differences and “impediments” first can certainly help to drive a more meaningful conversation when it comes time to give this exercise a try. And, bonus, it also encourages more empathetic teams!

Final statement — I’m far from being an expert on great estimation.

I would even accept that I may not know anything on how to estimate “properly”. What I do know is the value I’ve seen in having teams take on this exercise. They may still be challenged with sizing but they understand what other team members and teams have to face in order to get the job done. What I can speak to is the cross-team transparency it has provided in my organization and the collaborative conversations that can come out of being more aware of the effort a team is exerting to move the needle forward. Finally, what I would suggest to coaches, SMs, and POs is this: there’s no harm in giving this a try.

At best, you have a solid process in place that provides valuable context around estimation and can help deliver more predictable velocity and overall effort. At worst, your team has outlined what it is they need to do in order to contribute to the overall goal and can provide perspective on how you can help support them each sprint or iteration. That, my friends, is the root of all successful teams, scrum or otherwise: teams that understand, support, and value what each other contributes in order to deliver on our goals.