We all know that having a good sprint goal is very important for any team, but do we all know how to define it?
In some cases, the team is not able to define a sprint goal at all because they basically consider it optional or they don’t know how to do it and as result they don’t see how to benefit from it.
I admit that in the past, I worked in different teams who were used to work without a sprint goal. Here are some of the related issues we faced in our daily work:
- The team is not able to deliver working software at the end of a sprint
- Team members focus separately on their own goals and don’t work toward the same goal
- The team doesn’t focus always on implementing the most important features
- Bottlenecks occur frequently in testing and code review which prevent work from being completed
- Lack of collaboration between team members
- Team members remain specialized in a particular area of product
- The daily meeting becomes a simple status report
In one occasion we tried to define a sprint goal to tackle some of the problems mentioned above but we failed. At that moment, we thought that we did well but much later we discovered that we defined a bad goal. Here are some examples:
- Complete user stories A and B
- Fix high-priority bugs
As you have noticed, those goals do not describe any special purpose for the sprint; they are generic and encourage the team to focus on completing tasks instead of delivering value to customers.
With a good sprint goal, we enforce the importance of having a real objective that is aligned with customer expectations. Now the question is, how do we actually define a good sprint goal?