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.
Working without a sprint goal
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
Bad sprint goal
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.
Good sprint goal?
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?
Top comments (0)