In my last post I stated that 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.  I also wrote that the keys to planning are priority and effort, allowing the team to pull as many of the most important items as possible into a given sprint and giving flexibility if they find capacity changes.  Here I want to share some thoughts on the best ways to do sprint planning.  As always my ideas are informed both by the reading and thinking I do on this topic and by things that I have seen work well in my current context; and of course all ideas are ultimately my own so direct your critiques my way here or on Twitter @asbiv.

We are spending a lot of time and energy thinking about the best ways to plan in my current company, so many of the topics I’ve been writing about are issues we have been wrestling with in the past few months.  As regular readers of this blog know, I work closely with two project teams and have been doing so for the past year or so.  One of the teams is smaller and focused on adding specific features to a developing product; the other team is larger and working on multiple facets of a product with more users in the marketplace.  Both teams work in two-week sprints and take time for planning both short-term and longer-term items to be addressed.  As these two teams (and the other development teams across our company) have learned about and practiced sprint planning, three essential components have emerged that make for effective sprint planning:

1. A prioritized backlog free from clutter
2. Appropriate estimates of near-term items (2-4 sprints)
3. Balancing the need for refactoring with the desire for new functionality

In our experience, doing sprint planning well on a consistent basis requires these three key elements.

For some product teams, the backlog becomes a veritable dumping ground for any idea, tweak, enhancement, feature or product change that has ever come up.  Unfortunately this makes the backlog almost useless for planning purposes, since it is cluttered with ideas of questionable merit many of which may never get worked on.  I’ve written before (for instance here and here) about the importance of grooming the backlog to make sure it captures the items that the team actually plans to work on and indicates some level of priority for the items.  The other element of a strong and useful backlog is that items are clustered around elements of usable functionality.  The teams with which I work think of these as epics and user stories which provide adequate detail on the important aspects of functionality to be developed and prioritized (you can find hundreds of pages on the web about these concepts, but why not start here if you want some basic information).

In addition to a prioritized backlog free from clutter, the second key requirement for effective sprint planning is having appropriate estimates for near-term items.  If as I stated above the keys to good sprint planning involve knowing priority and effort, then this second component provides insight into the effort anticipated in developing the next pieces of important functionality.  A motivated development team can pull what they have capacity to work on from the prioritized backlog in an informed manner when they know the effort involved in completing a given task.  Working with the product manager and product owner, the development team can plan how much to commit to for a given sprint by reviewing the estimates of the highest priority items and deciding together what clustered sets of stories to work on.  Assessing the effort involved can also feed helpfully into the prioritization process itself; a new feature might seem more important to build if the effort required is relatively small but less crucial if it would require a larger investment to develop.

While there are many different ways to create estimates for items on the backlog, planning poker is one that the teams I work with have found helpful.  This simple process (which you can read more about here if you’re interested) allows the team to collaboratively decide the relative effort of a given task while also ensuring that estimated items have appropriate levels of detail before the team commits to delivering the requested functionality.  The same end result can come from collaboration between the product owner and development lead determining the approximate effort (as in small, medium, or large) and the development team further estimating more detailed tasks to gain greater granularity and precision on the estimates.

While understanding priority and effort are fundamental to engaging in effective sprint planning, the third element I mentioned above – balancing the need for refactoring with the desire for new functionality – adds a vital ingredient especially for on-going development teams.  One of the central principles for Agile software development is that continuous attention to technical excellence and good design enhances agility, and this means that the team must give regular attention to cleaning up older code so that the product functions as effectively as possible.  Addressing this need shouldn’t be left to chance or squeezed in if there is time; instead the teams I work with make it a priority to spend some time each sprint refactoring existing code even as we also build out new features.  Of course, this refactoring should have understandable business benefit for the product manager in terms of enhancing scalability, speed, or reliability for clients or reducing the support burden for the team.  This keeps ongoing investment in the product codebase as part of the overall set of priorities for the product.

As I mentioned in my last post, there is a ton of material available on the web and elsewhere about sprint planning and estimation.  Here’s a link to a set of articles exploring these topics if you’re interested in learning more: http://bit.ly/1nyHBn4.  Planning well is crucial to ensure that the team stays efficient and focused on moving the product forward.  Too much advanced planning wastes time because priorities change, new things are learned, and unexpected issues arise; on the other hand, too little planning means the team doesn’t know what to work on or doesn’t have enough information to start working on prioritized items.  A prioritized backlog with meaningful estimates on near-term items provides valuable insight as the team does its planning, while balancing continuous improvement on existing code with development of new features allows the team to plan progress in both key areas.  When the team knows the priority of issues in the backlog and the effort required to address the near-term items, they can make plans about what pieces of working functionality they can commit to delivering with relative certainty for a given sprint.  Planning this way doesn’t solve every issue that might arise for a team of course because in truth it’s not that simple.