The Criticality of Setting Expectations

The idea of setting expectations is a crucial part of being agile. This is, of course, not just because in the previous world of waterfall there were dates on everything but because it’s good practice to be transparent and help those outside the team understand the shifting direction of your product.

For teams that have not quite learned to embrace an agile mindset, there may seem to be a lot in common between agile and waterfall. There are still delivery dates, estimates on the work we do, and product roadmaps that can sometimes be mistaken for a Gantt chart of features to be released over time (if your roadmaps do look like project plans, please see Janna Bastow ’s Now/Next/Later roadmaps).

Unfortunately, there are often challenges in how a team presents their information in this aspect of trying to be agile. Our old ways of working seem to creep into this way of setting expectations as an agile team. And in some cases, agile teams that have not yet achieved a higher level of maturity will treat their backlog like items in a project plan that get sliced up into two-week increments.

It’s no wonder why our Sprint Review stakeholder audience hears everything as milestones and delivery dates and assumes these are guarantees. In this case, any changes or schedule slips are met with great opposition and dissatisfaction.

Whenever your team tries to set expectations about work to be done in the future, your have to reiterate that the processes we use in an agile environment deliberately change priorities often, so what may be important two or three months from now may change frequently as we learn new things and incorporate a very broad landscape of shifting priorities into our view of the future. Therefore, nailing anything down in the future is a fool’s errand.

Tips for Leaders

Firstly, it’s important to learn to understand what “velocity” actually is if you have Scrum teams. It should be considered a very private metric, not to be shared, to help you and the team understand that two things are happening properly. One is that the team is stabilizing in their ability to deliver value consistently, repeatedly, and reliably. A stable velocity is a great indicator of a stable team. Not exactly the same Sprint to Sprint, but more or less stable. The other thing is that the team is working at a sustainable pace. If they attempt to work on a reasonable amount of work and deliver it every two weeks, that is how it is supposed to work.

Estimation is a dangerous topic in many corporate cultures. As the manager of a team, your job should in part be to help your team better set expectations with stakeholders and senior leaders, helping them to understand how the agile process works. Any time there is talk about delivery dates and anything that might be indicative of a fixed-scope, waterfall mentality, I think the manager of the agile team should work to help people unlearn those behaviors.

Instead, we need to educate about how the team is validating hypotheses all the time, every two weeks, and the course of delivery will change frequently by design. Messages that resonate with senior leaders include emphasizing a lean savings perspective. By learning what not to do sooner, the team is saving time and money by not building things that don’t matter and focusing more on the things that do. This is the shift we should come to expect from agile teams. If we deliver features blindly, without ever changing our minds on what to build and why to meet long-term delivery milestones, we are doing our customers a disservice.

Tips for the Scrum Master

When a team is estimating, a Scrum Master should be present but doesn’t need to facilitate. They should however pay close attention to the conversation and look for opportunities to prompt important discussions that lead to a more thorough shared understanding of the work being discussed. During poker planning, for example, ask the question to prompt a conversation about why team members may have different ideas about the work. The shared understanding is more important than the estimated story point number.

Perhaps even more importantly, a Scrum Master should be actively helping a team get to the point where they no longer need to estimate. If the team works on building smaller user stories that are vertically sliced and still delivering value, this is more important than anything about the act estimating. Getting to a shared understanding about how the work achieves the desired outcomes is paramount. The work to get here can be difficult, but the rewards are important.

The Practical Agilist Guidebook

This blog post above contains excerpts directly from Topic 9 of 24 in The Practical Agilist Guidebook. Each “chapter” in the book is a topic that represents the behaviors behind the Agile Mindset that every team needs to embody to truly be agile. I believe this may be true for any kind of team, whether you work in software, marketing, or something entirely different.

The chapters (as topics) include first an explanation from an Agile Coach’s point of view about why the topic is important and any relevant background or stories to help explain the concepts. Then there are tips for Leadership, tips for Scrum Masters, and also includes a handful of AI prompts to type into any tool like ChatGPT to do more research to learn more on your own.

Each topic also highlights a summary of the human behaviors related to the topic, answering the question “What do team members do when they embody this concept?” This is usually a list of four behaviors and includes examples of what the low, medium, and high levels of maturity look like for a team as they represent the behavior along the path to maturity.

For example, in Topic 9, the first behavior is “Completing Work” which is a behavior you will notice the following changes along the path to maturity for an agile team:

To learn more, please consider the book on Amazon in either Kindle or Paperback format as a guide to help you as a team member, a Scrum Master, or Leader learn and work to evolve your behaviors in an agile environment.

This post is inspired by Topic Nine of the Practical Agilist Guidebook.

If you enjoyed this, please like and share. It means a lot to know my work on this blog is read and used by agilists out there in the world.

Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the complexity of the agile universe into easy to understand and simple common sense.

The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an Agile Coach teaching you the behaviors behind the Agile Mindset, why the topics are important, and what you can start doing about it. It also includes Scrum Master and leadership tips, AI prompts to help you explore topics and dig deeper, and tons of recommended books, videos, and articles.

Paperback and Kindle Available on Amazon.