Goal Setting in an Agile World

A friend recently sent an email to me asking this question:

We are introducing a “new” goal-setting system (meaning we’re just emphasizing the need and value of setting goals) and are also emphasizing agile development in engineering – which means we are running into the classic “but if we’re truly agile, how can we set goals more than a sprint or two out” argument. Wondering if you have any insight into the types of goals that teams running scrum can set – both individually and as a team.

Setting personal long-term goals is an area of self-improvement. To break that down into smaller chunks that could be completed in a given Sprint (my time or the company’s) is a great way to ensure I am making progress against this goal. If this is formal, I can make a plan with my manager and turn that into a personal backlog. Having a personal backlog for self-improvement is a powerful mechanism, assuming I respect and use it.

Team level goals are similar, and it often helps to take a goal and break it down into actionable deliverables or changes in behaviors that a team can try in a given Sprint. We’d not want to vary more than one or two variables per Sprint, but keeping a backlog of steps to get to that goal is important to continued pursuit of it. In this explanation, I am assuming we aren’t talking about product goals, but actual team goals. Things like, “We need to create a CICD pipeline.”

Projecting out a deliverable in terms of product features is only slightly different. One can decompose a feature or set of features into a larger product backlog and estimate the items in that product backlog, giving the Product Owner what they need to roughly forecast into the near-distant future. For far-future product goals we simply recognize 3 things. 

1. Using a team’s velocity, we can forecast into the future most likely delivery dates a feature will be ready or most likely features a product will have by a given date. We cannot fix scope in a time-bound delivery model. We cannot fix time in a feature-focused delivery model.
2. We may decide to pivot our product direction mid-flight and that needs to be okay, because we will likely only do so to provide more value to a customer in less time. This can leave a product backlog in place that we worked hard to create, but may well abandon.
3. Any requirements we don’t implement were waste. We spent time to create, estimate, and manage them, but chose not to implement them. This isn’t heresy, but we should realize that work decomposed to the team level will likely change, especially work projected farther out than 3 weeks or so.

 We must set goals to work toward, even in agile work places, but we realize the goals may change as we learn more while building out our product and frequently delivering to our customers. Goals aren’t bad and they aren’t anti-agile in any way.