How to hold effective Agile sprint planning meetings

Who should attend Agile sprint planning meetings

These meetings are a collaborative effort, but you might not want too many voices in the room. Determine who to invite to sprint planning, and how often the meetings occur.

Typically, the product manager, developers and QA professionals or testers come to Agile sprint planning meetings. The project manager, a development or QA manager and the Scrum Master can join as well.

The project manager might participate to better understand the project status, so they can assess the time needed to complete it -- with quality. Often, the project manager has one view of the timeline, while the rest of the team has a totally different view.  Project managers can mitigate timing issues and prevent surprise release dates when they attend sprint planning meetings.

The development and QA managers must consider the big picture, but they need to know about details to put it all in perspective. Agile sprint planning meetings give managers insight into what it takes to achieve the overall goal. Development and QA managers are often surprised when sprint stories aren't completed, sprints extended, or stories broken up and disbursed over upcoming sprints. When Agile management is in the room, it ensures those people outside of the development team have an accurate view of the project and the work tasks. When these managers are present, they make fewer incorrect assumptions about items in progress.

It's a team decision who to invite to the meeting. Many teams prefer not to have any type of manager in the meeting. If that's the case, only invite the product manager. Then, designate someone to update the rest of the Agile management team.

When to plan your Agile sprints

The team must also decide how often to hold the sprint planning meetings. More Agile sprint meetings mean more interruptions to development work.

Each meeting should happen before the current sprint ends and the next one begins. Commonly, planning meetings occur during the last week of an Agile sprint iteration.

If the team needs more than a single Agile sprint planning meeting, consider adding a free day between sprints, when a more exhaustive planning session occurs. With this approach, you can meet quickly during the current sprint only when necessary -- team velocity is key. Keep in-sprint meetings brief and to the point, so as not to disrupt the team's focus.

How to keep sprint planning effective

The Agile sprint planning process schedules out planned work, but a lack of foresight can limit its effectiveness. The most common mistakes that occur during Agile sprint planning meetings include:

• failure to account for company holidays, team vacation time and possible sick time;
• creation of user stories that are too large and contain multiple tasks, instead of small, distinct coding efforts;
• skipping the development design discussion, a mistake which results in features that the team cannot code according to the product manager's wishes;
• not allotting time for testing;
• failure to account for defects and retesting time; and
• defining too small of a scope, then changing it mid-project.

Use an agenda or a checklist to make sure you cover all points in the meeting. The better the product manager and development team prepare, the fewer disruptions occur during the sprint.

Several of the mistakes on this list relate to defects. Always plan for defects. Capable developers create brilliant projects, but that doesn't mean zero problems in the code. Developers can also inadvertently create a bug when they work together within one code base. When a developer doesn't properly understand a system function, their changes can cause a bug in another part of the application. Even after integrated unit testing, defects will pop up in the application workflow. It's simply the nature of the beast; unless developers understand the code 100% and the back-end OSes are 100% stable, code defects will happen. So, allot time to address defects and retest in advance.

Why user stories matter

Early on in an Agile development sprint, the product manager grooms sprint backlog items, sets user story priorities and comes up with the sprint goal. When the stories are ready, the Agile team plans the next sprint. At the Agile sprint planning meeting, confirm the entire team understands the product manager's goal, and pull in stories that fit that goal. The sprint goal can help define which stories the group can complete within the sprint schedule. Development and QA teams should estimate time per user story.

To keep a sprint in sync and a release on schedule, control expected scope. Often, developers must break up stories too large for a single development task to keep in line with the defined scope.

Developers should organize stories into logical sets that build a particular application feature. For example, a single sprint can contain a mix of rudimentary stories that build the back-end code base and feature-oriented stories that enhance the application.

Stories might lack information or details developers need for coding and testers need for testing. Furthermore, you'll have more stories than you originally imagined, and it's a real challenge to keep them on track and organized from start to finish.

In some companies, a Scrum Master ensures the team remains focused on the sprint goal and planned work tasks. If the team doesn't follow Scrum, the development manager or team lead might perform the Scrum Master's duty.

When the team should finish its sprint

Define exactly how your team should measure time for estimating development work. For example, a team might want to use story points instead of hours. Make sure everyone on the team uses the same time method to ensure consistency. When you use hours, include time away for meetings or other nonproductive work tasks.

You need a good estimation of the Agile sprint length, but it doesn't have to be precise -- just realistic. Generally, code development takes twice as long as that code's tests. But team members perform work at different rates. What takes one developer an hour might take another developer three hours. Time invested depends on the developer's experience with the code base and how much unit testing he performs before moving the story into QA.

To equalize development time, you can enforce unit test creation, which ensures new code passes a set of integrated unit tests for each code check-in. With this strategy, all developers spend time creating unit tests that send a higher-quality software product to QA for further testing.

How to visualize work on the sprint board

An Agile planning board must make it easy to visually understand the workflow. With a look at the board, the team must be able to track progress of work and see assigned tasks. The team should update and move items on the board. The sprint planning board creates a shared understanding of the work in progress.

Keep the Agile sprint board updated so the entire team sees how work is progressing. Visualize and discuss blocked items and test failures. The only way to clear obstacles is to eliminate them -- not to ignore them.

The product manager should only put the assigned tasks for the sprint on the board. Don't put up all the product backlog items and try to sort through them.

Team members must document and move user stories in a timely manner as part of their work process. When the entire team keeps the board updated, everyone knows where the current sprint stands and whether replanning will be necessary before it ends.

Some teams use a physical whiteboard with sticky notes or cards they move physically across the board. Analog sprint planning boards make progress easily visible to anyone with office access. However, these analog boards don't work well for remote access. They're also vulnerable to minor chaos within the office space -- a clumsy co-worker can erase a work task or knock cards into the wrong place on the board.

Digital sprint planning boards are easier to update than analog boards. Digital boards are visible to team members at headquarters, at home or anywhere else around the world. While the choice of Agile planning software isn't as important as how a team uses it, there are numerous sprint planning tools to visualize work, including:

• ActiveCollab
• Atlassian Jira
• Rally Software
• SpiraTeam
• Trello
• VersionOne

Once you select a board, physical or online, set it up with columns the team agrees on. Some common column options include:

• To Do: the development work pulled from product backlog items for the current sprint.
• In Progress: what developers are coding.
• QA/Testing: cards move here after development, for testing.
• Done: features ready for release.

Your team might opt for more columns, but keep it as simple as possible.

With Agile sprint planning, even if you have to replan or reorganize, you can keep work moving, and the team can remain productive.