Propose a Sprint Goal Before Planning the Sprint
Originally written: November 25, 2019
In our team’s Sprint Planning meeting today we quickly veered into a detailed discussion about if and how we should manage the email subscription preferences of our users. For context, we are building out a service to proactively email users about insights we have gleaned from their data that we think they’ll find interesting. We have just finished implementing our first type of insight are beginning to receive some user feedback. This discussion in Sprint Planning was about how to manage user preferences with regards to the emails they will receive. Should we continue to use the built in functionality supplied by our email provider? Should we build our own logic? That sort of thing.
After about 20 minutes of discussion, it occurred to me that we were wasting time discussing what should’ve been called out as a secondary concern. Our primary concern was releasing valuable insight emails to our customers. We needed to focus on providing value before thinking about optimizing the flow. For us, this meant that we should have spent time thinking about how we were going to iterate on the actual insight emails (based upon user feedback) and how we were going to building our second (bigger bet) type of insight. Once I brought this up, everyone agreed and the conversation shifted towards a discussion around these higher priority topics.
The learning here is that at the beginning of Sprint Planning, we should propose what our Sprint Goal will be. Once everyone is aligned on the goal, we can begin planning around that focus. After discussing the necessary work in detail, we may find that we need to adjust our goal but that is ok. The important thing is the alignment of purpose that everyone has.