Scrum - Part II: Sprint planning

Having talked in my first post on daily (or not-so-daily) stand-ups, I'd like to share some of my experience around sprint planning.

Let's start with the classic approach, that I'll quickly glide over, as it's far better described elsewhere.

A Product Owner comes with pre-sorted backlog of items that have been previously estimated by the team, and together with the ScrumMaster and team members agrees on which of those can enter the next sprint.
Sounds easy enough, so it's time to throw a couple of spanners in the works!

Let's say we have a team of 6 guys on a project: two UI engineers, two QA and two back-end/middleware developers. We are implementing a media player, and the project is nearing its Alpha stage.
The product owner has the following list of items in the order given:

a. Integrate Chinese UI localisation provided by an external agency.
b. Enhance skin support for more customisation.
c. Address 3 visual defects.
d. Support two more codecs.
e. Prepare high-level effort estimate for porting to the MacOS platform.

UI engineers can do only (a) and (b) in the sprint, so where do we end up? Do we let the middleware guys work on (d) even though it's less important than (c)?
What if we have another dependent platform team that needs input from us on MacOS? For sure, it's not the top priority, but if we do not inform them in advance on what we require, we might not be able to start working on (e) for a while.
Lastly, even if UI engineers can work on the first two items, they are unlikely to complete either them before end of the sprint, which might leave QA with nothing to do. If we worked on (c), we could have the pipeline to QA going and keep everyone busy.

Of course, my example was very much Scrum-friendly: what if we have a module team of eleven people working on six projects, most already in flight, all with a complex network of dependencies?
Inevitably, the backlog order becomes just one of the many factors with deciding what enters a sprint, and the mythical line that defines sprint's contents becomes a bit similar to the Netherlands-Belgium border.

It's always easy to say what does not work, but it's harder to provide an alternative. Usually, the pattern I've been following was along those lines:

1. Figure out priority order. (Yes, it's still there!)
2. Balance tasks within the team
3. Check dependencies to other teams
4. Consider longer-term planning
5. Ensure pipeline of developed features to QA, and of tested features to release

Coming back to the media player example, our priority order was:

• Integrate Chinese UI localisation provided by an external agency.
• Enhance skin support for more customisation.
• Address 3 visual defects.
• Support two more codecs.
• Prepare high-level effort estimate for porting to the MacOS platform.

Balancing tasks within the team we end up with (i.e. give the middleware guys something to do):

• Integrate Chinese UI localisation provided by an external agency.
• Support two more codecs.
• Enhance skin support for more customisation.
• Address 3 visual defects.
• Prepare high-level effort estimate for porting to the MacOS platform.

Counting dependencies and longer-term plan (i.e. figure out dependencies with the platform team and get a better understanding of MacOS for following sprints) we get:

• Prepare high-level effort estimate for porting to the MacOS platform.
• Integrate Chinese UI localisation provided by an external agency.
• Support two more codecs.
• Enhance skin support for more customisation.
• Address 3 visual defects.

 Finally, we need to give QA something to do. They could do planning for some of the bigger tasks, but it seems worthwhile to get the defects out of our way as well and provide at least some customer value within the sprint. So this is the final result:

• Prepare high-level effort estimate for porting to the MacOS platform.
• Address 3 visual defects.
• Integrate Chinese UI localisation provided by an external agency - start development and QA planning
• Support two more codecs. - start development and QA planning
• Enhance skin support for more customisation.

In short, planning is an art, and simply using a descending priority order is a gross over-simplification. In future posts, I'll attempt going over various other factors that affect planning, such as expected load, planning spikes, and pinning tasks to future sprints.