On paper, Agile sprint planning doesn't seem complicated. But, in practice, it's no simple undertaking.
Agile sprint planning is a continuous process that requires a combination of diligence, organization and realistic time forecasting. In order to prepare for an Agile sprint, for example, one will need to establish the sprint's goal and scope and then come up with a plan to get every task done on time.
Teams will encounter challenges along the way, but a thorough plan will help get them through it. Here's what that Agile sprint plan should include.
Set an Agile sprint planning meeting
A sprint often involves a continuous flow of planning, replanning and reprioritizing. However, it's still valuable to hold an initial sprint planning meeting for all development team members and the product manager.
The most common mistakes that occur during sprint planning 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 cannot be coded according to the product manager's wishes;
- lack of time allotment for testing;
- failure to account for defects and, consequently, retesting time; and
- defining too small of a scope, then changing it midproject.
Use an agenda or a checklist to make sure all points are covered in the meeting. The better the product manager and development team prepare, the fewer disruptions occur during the sprint.
Always plan for defects. Capable developers create brilliant projects, but even they will generate defects, especially when more than one developer works within a code base. Often, new developers don't properly understand a system function, and they inadvertently create a bug in another part of the application. Even after the execution of integrated unit tests, 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.
How user stories factor in
Early on, the product manager typically grooms the backlog and sets story priorities. She also comes up with the sprint goal. After the stories are ready, the full team plans the sprint. At the aforementioned sprint planning meeting, confirm that the full team understands the product manager's goal and pulls in stories that fit that goal. The sprint goal, in turn, can help define which stories can be completed within the sprint schedule. Development and QA teams should estimate time per 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 more feature-oriented stories that enhance the application.
Also, keep in mind that stories can lack information or details that 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 synchronized and organized from start to finish.
In some companies, a Scrum master ensures the team remains focused on the sprint goal and tasks. If the team doesn't follow Scrum, the development manager or team lead might perform that duty.
Set realistic timelines
Define exactly how your team should measure time for estimating 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 events.
Time estimation doesn't have to be exactly precise, but it must be realistic. Generally, it takes half as long to test as it does to code. But keep in mind that team members perform work at different rates. So, what takes one developer an hour might take another developer three hours. It all depends on his 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 that new code passes a set of integrated unit tests for each code check-in. With this strategy, all developers will spend time creating unit tests that result in a higher-quality product when it goes to QA for further testing.
Update the board
Keep the sprint board updated so the entire team knows how work is progressing. Make sure to 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 sprint stories on the board. Don't dump the full backlog of work and try to sort through it. Team members must document and move their stories in a timely manner as part of their work process. When the entire team keeps the board current, everyone knows where the sprint stands and whether replanning will be necessary before the sprint ends.
With Agile sprint planning, even if you have to replan or reorganize, you can keep work moving, and the team can remain productive.