What to do when there's not enough work related to the Sprint Goal?

Question

We have enough work to do to fill two weeks (our Sprint length) for the Team.

We have a Sprint Goal.

We do not have enough work to do for the Sprint Goal to fill two weeks for the Team.

---

As a result, we end up with one person working towards the Sprint Goal and the rest of the Team working on less-important, unrelated tasks.

I'm unsure what the best way forward is, here. Things I've considered:

1. Status quo. Problem: The Sprint Goal is a minority of the work being done during the Sprint. While this doesn't cause any outright fires, it's not optimal.
2. Change the Goal to be more encompassing. Problem: The Goal also becomes more vague. I want to avoid "Complete Stories A, B, D, and F" as a Sprint Goal.
3. Swarm. Problem: It's often not feasible to have our entire Dev Team (of 4 people) focus on a relatively small piece of work. We get more done by having some people focus on lower-priority Stories.

Is there a solution/approach I'm not seeing? Or a problem I'm misconstruing?

Answer 1

It is worth reminding yourself that the sprint goal is a solution to a problem.

Some teams may drift a little during a sprint if they do not have a clear focus and an understanding of the value the sprint delivers. The sprint goal helps teams to avoid this.

The question to ask yourself then is:

Given we do not have enough work to do for the Sprint Goal to fill two weeks for the Team, are we losing focus as a team or are we struggling to understand the value of this sprint?

If the answer to the question is that the team is still working in an effective way, then it isn't worth worrying about. If, however, the team is experiencing the problems that the sprint goal were intended to prevent then you need to consider adapting your process.

Which adaption you chose will depend on the root cause of the problem. I would suggest sitting down with the Product Owner and thinking about the way that work is being prioritised and trying to understand the vision they have for the product.

Answer 2

The Sprint Goal is a focusing tool for the Development Team. It is not necessary for all work selected for a Sprint to be aligned with the Sprint Goal. In fact, I usually recommend that the Sprint Goal should be something that can be met through the completion of at most about 60-70% of the Product Backlog Items selected for the Sprint. If the Development Team is aware of what work is directly supporting the Sprint Goal and what work isn't, it gives them flexibility to self-organize and self-manage toward achieving the goal. If things come up and the effort to do the work that is aligned with the Sprint Goal ends up being more than expected, there's a little bit of buffer room and the team knows what work is most important to focus on.

The only concerning thing here is that one person is working toward the Sprint Goal. This seems like people are siloed, rather than working collaboratively. There's insufficient information in the question around this, but if I was working with the team, it would be something that I would probe around.

Answer 3

First, I think it should be stated that wierd stuff happens sometimes.if this was an odd circumstance that happened in one sprint, I'd shrug and move on. However, it sounds from your question that this is a frequent problem.

There are three likely causes (or a combination of them).

1) your view of the product is too short-sighted. Scrum is meant to be rapidly adaptive and planning should be just-in-time, but it is possible to take this too far. If you are only looking one small feature out, you may be creating problems for yourself.

2) you may be unfocused. I've seen teams that work on multiple areas of the product at once and then pick one to be the sprint goal, meaning they are only speaking to a small portion of their work. Usually, the answer is to focus the sprint on one or two areas, but in the rare cases that working in multiple areas is the right decision, a few sprint goals may be beneficial.

3) your sprints are work-focused, not increment-focused. A lot of teams make this mistake. They load up the sprint with work tasks, then try to form a sprint goal. In all fairness, the scrum guide points people in this direction, which is problematic. A team should start by understanding what would be a great increment of the product and then pull in the necessary backlog items to fulfill that. If this is the case, if that increment is too small, you just describe a bigger increment.

Answer 4

I think of the options you have listed you should choose #2

Change the Goal to be more encompassing

...even if that means the goal is more vague.

Let's face it: the sprint goal is always going to be some variation on "build value for the organization" anyways.

It sounds like the goal is getting in your way and I am going to guess that is hindering the team more than helping it by creating a sense of uncertainty.

I think the agile thing to do is adapt to the circumstances. I'd focus more on getting work commitments from the team members in pursuit of the common goal rather than focusing on specifics.

Answer 5

The sprint goal is typically a short missive you can communicate in business terms. For instance,

We want to deliver the customer profile page

If that takes 1 day or 2 weeks, mission accomplished. In fact, as a business, you would rather have it in one day than two weeks, wouldn't you?

The artifact of people must appear busy comes from an idea that time spent working is valuable, as opposed to its outcomes. The business is paying for these people whether or not the business goal is met, so let's try to get as much out of them as possible, is the the thinking.

A corollary to that equating time with value is that the stuff that is needed to keep the lights on, or to make delivering the next business goal easier, isn't valued as much.

The people who build and collaborate to create software are humans, and therefore software itself takes on the same level (if not more) of complexity as the humans that created it. That complexity needs to be pruned, managed, and kept at bay. We sometimes call this "refactoring", and sometimes we call it "maintenance", but we should probably be more precise in our terminology. Sometimes it's scaffolding (akin to the scaffolding used to build buildings but that disappears after the building is built), sometimes it's adapting to changes in the environment; and sometimes it's reacting to changes by external actors.

Software is not a closed system, and so it is affected by everything it touches or that touches it.

I say all this to say that the slack time afforded by a sprint whose goal was completed early is a blessing for you and your team. Use this time to scaffold, or adapt to environmental change, or react to changes by external actors (like making your build system more resilient to NPM outages if you run a node.js stack, for instance), or to refactor or improve the maintainability of your system.

These are all unseen and yet critically important activities that more businesses and teams need to devote time to to ensure their business goals can be met in a timely manner.