When I was first tasked with leading an agile team, it was very important to me that I nail the planning ceremony of my first sprint. I had a series of precise questions to help lead the team in identifying the most important features needed and was determined to get there. In my head, I knew what they were so I just had to make sure they understood it.
You can guess how that turned out.
The meeting meandered as the team discussed different dependencies each feature would have. Clearly I had not thought all of them through, nor had they, and the meeting went seemingly never ended. When we finished, we established the next needs but it set a terrible tone for the work we would do for the next two weeks.
As this well written blog post points out, I was missing one of the key elements to an effective sprint: a goal.
The goal is nothing more than the objective for a development iteration. Regardless of your industry or workflow framework, a goal is something everyone can agree on.
So why is it overlooked so much?
Perhaps the concept of setting goals seems great in theory but difficult in execution. If your team works on maintenance tasks, or supports another team’s efforts, how do you write a goal for a seemingly innocuous list of activities?
The important thing to remember with goals is they won’t always be the type that are written in stone for all the world to see. There’s no shame in setting a goal of closing a number of defects that is just a bit higher than you would normally achieve. You could set a goal related to something usually outside your purview. The goal could be process related.
Of course, once the goal is set you have to make sure that the activities you perform work towards that goal. The beauty of it is if you plan with the goal in mind, you will make sure your tasks accomplish it.
I had a good friend once tell me the job of the team’s leader is to set the goal just a little farther than the team would set for themselves. While that may not always apply to the goal, it is important to ask more from yourself. That doesn’t mean you work 60 hours that week to achieve it, just work with that goal in mind.
Adoption will work differently in every organization, but if your team gets this down you will see a marked improvement in the shippable work they achieve every sprint.