We are just past the halfway point in this sprint and so one of the things I am doing as the product owner is to review our sprint goals to see how much of what we planned to do will actually get finished this sprint. Doing this review brings up two topics I want to mention briefly here. Both of these ideas could get a lot more attention (and probably will in future posts) but for now let me toss out some ideas that have more complexity behind them than I will unearth in this piece.
First I want to say a few words about writing sprint goals. One of the things that I’ve been working on over the past year is getting better at writing sprint goals. I used to simply state what feature we were adding or bug we were fixing – things like ‘we are adding a button to trigger the report,’ or ‘we will fix the UI issues on this screen.’ But these don’t make particularly compelling goals or especially interesting release notes. Because we try to use the sprint goals – written at the start of the sprint – as the basis for any release notes we create at the end of the sprint, I’ve been trying recently to format my goals as story summaries. ‘At the end of this sprint the user will be able to’ is how most of my sprint goals start now. This gives a clearer picture of what we are trying to accomplish, why it matters, and how we will know if we succeeded. They are also easier to communicate to clients, prospects, sales, management, and anyone else with an interest in what our team is working on currently. In addition, sprint goals written in this format make tracking our overall progress on a project much cleaner; we can see sprint-by-sprint progress on larger feature sets by chunking the big tasks into smaller pieces. These goals are then broken into individual ‘tickets’ by the development team as they code and test aspects of the feature. Finally, well written sprint goals are more in line with the Agile idea of providing outcomes rather than requirements for developers. The coders and testers are better at figuring out how to accomplish the goals than I am as a product owner and so I want to give them as much freedom as possible to find the best methods.
Second I want to talk about the point of stating goals in an Agile project. If you’re reading this blog you probably know that I am also on twitter (@asbiv). I recently saw and retweeted a great quote that captures what in my opinion is a key aspect of Agile development. It’s from Chris DeLeon (@ChrisDeLeon) and here’s what it says: “Any creative project that ends up incomplete could have instead ended up smaller and complete. Any amount of time is enough if well planned.” One of the key things we work on as a team when writing and agreeing to sprint goals is to make sure that we commit to what we think can actually be done. Over-committing comes up as a topic in our retrospective as something to learn from so that we can avoid it in the future. I work with the product manager to define what constitutes ‘working software’ at the feature level and we then try to release a defined set of this each sprint. Of course there are times when a complex feature might take more than one sprint to get into a ‘releasable’ state – or times when unexpected issues arise that cause us to revisit our plans or priorities. But we strive for ‘smaller and complete’ each sprint rather than expecting that everything we work on will take an undefined number of sprints to finish. This forces us to understand our sprint objectives and keeps us focused on the Agile principle that states, “Working software is the primary measure of progress” – although I would add that sometimes creating ‘working software’ in a sprint might mean refactoring existing code or developing automated tests around a core feature.
So as I review our stated sprint goals at the midpoint of this sprint, I am asking not only how we are progressing toward our goals but also how well we are understanding and planning our product and its features. Certainly we sometimes encounter unexpected situations that force us to adjust our plans (I wrote about one last week). But in my opinion we should be getting better and better at creating sprint goals that define a small fix or feature we can confidently complete in one sprint. If we plan our time well then transforming sprint goals into release notes becomes a much clearer process. Of course, in truth it’s not that simple.