Early on in this set of blog posts about Agile planning I talked about the common image of the planning onion, in which there are different layers of planning that start with the widest strategic view and progress all the way to daily planning.  So far I have written about strategy and portfolio planning in the earliest blogs in this series, then progressed to talk about product and release planning when sharing thoughts on product roadmaps.  Now I’d like to focus still further in and discuss planning for a specific sprint or iteration.  In my current context we work with two-week sprints and so my thoughts relate to team planning for a given two-week period of time.

This is really a huge topic; I could create several posts about it and people have written whole books on sprint planning.  Maybe I will write more extensively about this topic in the future, but for now I want to share thoughts on two big areas (broken into two posts):

1. What is the goal of sprint planning?
2. What is a good way to do this planning?

Weaving through both posts will be the idea that the key to effective planning is understanding priority and effort – relatively how important and how difficult are the various tasks.  This allows the development team to pull as many of the most important items as possible into a given sprint while also giving them flexibility if they find capacity changes.  With all of this in mind, let’s begin by talking about the goal of sprint planning.

To understand the goal of sprint planning, it is useful first to think about the reasons for developing software using an Agile methodology in the first place.  In this context several of the principles behind the Agile manifesto standout to me, including these:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

Working software is the primary measure of progress (for a complete list of the Agile principles see this link: http://agilemanifesto.org/principles.html)

The goal of Agile development with sprints is regularly delivering the most important increments of working software to the customer.

With this in mind, we can talk about sprint planning as having twin goals, one from the development team’s perspective and one from the viewpoint of the business.  For the coders, testers, designers, and architects working on developing the product, the goal of sprint planning is to make clear what they should work on next and roughly how much effort it will require.  For the business, the goal is to know what increment of working software they can expect at the end of the two-week sprint.  Pursuing these twin goals lets the development team know what to work on for the sprint and the business know what to anticipate from the sprint.

Taken together the goal of Agile sprint planning is for the development team to know what pieces of working functionality – prioritized by the business – they can commit to delivering with relative certainty at the end of the two-week sprint.  Regularly making and fulfilling sprint goals deepens the trust between the business and development teams as both come to understand the capacity or velocity of the team to produce on a consistent basis.  Certainly there are times when unanticipated problems arise that complicate development and compromise the team’s ability to deliver on the sprint goals – just as there are times when obstacles prove easier to overcome than expected and the team has added capacity at the end of the sprint.  However, making clear and realistic commitments through the regular process of sprint planning strengthens the relationships among the development and business team members as they together identify the most important things to focus on each sprint.  Disciplined planning promotes this focus as all the relevant stakeholders know what to expect each sprint.

In my current context I have seen greater benefits flow from sprint planning as we have invested more time in doing it well.  I’ll talk in my next post more about what ‘doing it well’ looks like for us, but for now I can confidently state that having the team take time to think through and plan its commitments for a given sprint makes the entire development process more satisfying both for the development team and for the business.  It doesn’t mean we never have problems meeting sprint goals or that we never have to abandon those goals mid-sprint when something unexpected occurs (you know that if you’ve been reading this blog for any length of time); but planning what we want to accomplish in a given two-week period and then tracking our progress against those goals energizes our team and deepens the trust that the business and sales folks have in our work.  Getting to this point hasn’t been easy of course because in truth it’s not that simple.