What Should Our Iteration Goals (Sprint Goals) Look Like?
The basic idea behind Iteration Goals (Sprint Goals) is that they represent a stepping stone in achieving the overall release / program objectives of the team. They are not just a list of stories committed. The way to think about this is to ask “at the end of the Iteration (Sprint) we will have X”. X is the goal. X, in most cases, contributes toward the release / program objectives committed by the Team. X allows to understand that “this was a successful Iteration (Sprint)” (if we achieve itJ). And, by the way, X should be SMART.
In some cases, we might be able to say that we got to the Iteration Goals (Sprint Goals) even though we did not complete all the Stories in the Iteration (Sprint). For example, as a result of understanding the Iteration Goals (Sprint Goals) and as we work the stories in the Sprint, perhaps we come up with some scathingly brilliant way of achieving the Sprint Goal that makes the stories we have meaningless. In these cases you should aim to achieve the Iteration Goals (Sprint Goals), not just march through the stories (focus on “outcome / result” not “output / effort”).
It should be noted that the Iteration Goals (Sprint Goals) are not always the directly related to the deliverable work of the Team. Some of them are going to be related to the Improvements the Team is taking on as a result of the Retrospectives. Making these part of the Iteration Goals (Sprint Goals) allows the team to make them happen.
For many Teams I work with the Iteration Goals (Sprint Goals) turn out to be pretty much a list of stories with the result that some teams do not bother. As said, that is not the intent.
Want to Know More?
- For a scaled implementation basic guidance for Goals is provided at SAFe’s explanation of iteration goals. There’s also a shorter blurb on the SAFe site in the iteration planning guidance page