Stop Feeding Teams With Tasks!

Developers don’t need tasks to execute; they need goals to?pursue

For years, I’ve thought about why onyle a few Scrum Teams become high-performing units while others don’t go beyond mediocrity. Until now, I haven’t found a single aspect that leads to high performance, but I identified one that kills the chance of it; lack of clear goal.

A Sprint without a goal is like a ship captain without a compass. He will get?nowhere.

How do you start your Sprint Planning? Do you define the tasks to deliver and then develop a Sprint Goal for that or the other way around?

A meaningful goal fosters collaboration and transforms a group of people into a team, while a shallow goal is just a sentence nobody cares about. Many times in my career, I heard sentences like the following from developers:

• I need more tasks because I have nothing else to do.
• I finished my Sprint. What should I do now?
• A bug came up. Should I fix it or not?

Whenever I hear such sentences, it’s clear that a meaningful Sprint Goal is absent. Beyond that, it’s also clear that the Product Manager is not empowering the team with a meaningful goal but giving them tasks.

Allow me to share what I learned from powerful Sprint Goals. Hopefully, you will get applicable insights into your situation.

Feed the?Beast

When I started my career as a Product Manager, I thought my job was to bridge the communication between business and tech teams. I spent most of my time talking to business stakeholders and writing User Stories. After that, I’d refine the User Stories with the team and plan them into Sprint.

The truth is, no matter what I did, stakeholders and developers were unhappy. On one side, stakeholders pushed for more. On the other side, developers blocked the gates as they couldn’t take more. On top of that, I became a bottleneck, stakeholders needed me to write User Stories and developers needed me to clarify them.

I missed the point of what it means to be a Product?Manager.

The tipping point happened around five years ago in the Dominican Republic. Back then, I was the Product Manager for a single Scrum Team, and we’d grow to three teams. After proving market fit, we received more funds, and it was time to scale up the team. I was in panic mode because I would still be the only Product Manager. Luckily a conversation with the most experienced developer on the team changed my life forever.

Dev: Hey, buddy. How do you feel about leading three Scrum Teams?

David: Honestly, I don’t know how I will do my job. I need to figure it out. The last months were pretty intense with a single team. I cannot imagine how it’d be with three teams. That makes me panic.

Dev: Well. You need to feed the beast. The point is how you are going to do it. You either give us food to eat, or you give us a monster to kill.

David: That’s it! I’ve got to focus on pointing out a monster to kill instead of providing them with food.

Dev: Yeap! We’re grown-ups already. It’s time for us to kill monsters. Just point us where to go, and let us figure out how to slay the beast.

My job was not to feed teams with tasks. My job was to inspire them to reach their?goals.

Killing Monsters

The conversation about how I could feed the team opened my eyes and changed how I think. I stopped pondering which Users Stories I should write. Instead, I started considering which problems we could solve. However, I couldn’t change how I work without the teams’ commitment. We had an intense talk and established a motto: We kill a monster per Sprint.

Instead of investing most of my time talking to business stakeholders, I started broadening my perspective by talking to users to understand their challenges. I used the refinement to evaluate the opportunities I identified. I did write User Stories, but they were no more than an invitation for a conversation. Our refinements became fun and energetic.

We also changed how we planned our Sprints. Teams didn’t want me to tell them which tasks to deliver but which monster to kill. We’d start our Sprint Planning by deciding which monster would be our next target. Then, we crafted a Sprint Goal together. It was fun. Our Sprint Plannings moved from a boring three-hour meeting to an energetic one-hour one.

The Effect Of Meaningful Sprint?Goals

For a long time, I didn’t understand the power of Sprint Goals. I started many Sprints without a goal or with a pointless one. I wanted to ensure we’d deliver at our maximum capacity. Yet, I missed the mark.

Delivering more features has nothing to do with producing value to end-users and businesses.

Scrum is powerful when teams are empowered to make decisions. Therefore, the result of Sprint Planning should be where to land instead of which steps to take. A solid Sprint Goal empowers the Scrum Team to:

• Decide what makes sense to do and what doesn’t.
• Function as a single unit moving in the same direction.
• Support each other in achieving the goal.
• Pivot when needed.

Let me share a couple of Sprint Goals I used with the team I mentioned:

• We’ve got a full schedule. Car owners can book a free inspection frictionless in two minutes.
• Auctions are bloody competitive. Dealers are eager to join auctions because we know their preferences.

Only The Sprint Goal?Matters

When planning a Sprint, it’s easy to fall into many traps. You may have clarity on the tasks to deliver yet have no goal to pursue. When that is the case, the Scrum Team will lack the needed inspiration to go the extra mile, and you cannot expect anything beyond mediocrity.

I am satisfied when the Sprint Planning results in a meaningful goal. That will empower the Scrum Team to do what matters most. After a decade on the road, I learned the following:

Nothing is more critical than the Sprint Goal during Sprint Plannings. Without a solid goal, Scrum Teams are like dogs chasing their?tails.