Sprint planning is the exercise of sizing up the work we think we can get done in an iteration. The recommended practice is to size the high-priority stories on the backlog in story points. Story points aren’t exactly well understood by most organizations, but those that do, more power to you.

We take stories off the backlog to package into a sprint not by how long we think they will take (we estimate that after we break down the tasks) but by the number of story points which indicate the complexity. On a team with at least two sprints completed, I always recommend not taking any more story points than were completely delivered in the last sprint – no matter what, even if they were really low due to some odd circumstance. We can always pull in another story if we finish early.

Now, there are teams out there that have a bit of a different mechanism. Stories are estimated in “ideal days” rather than story points. Then, each team member calculates the number of actual work days in the sprint for them (accounting for vacation and known absences etc). Then a more or less arbitrary “load factor” is applied to this number of days, a percentage of 100 (usually 66%) to find out how many “ideal days” worth of work time we have available each sprint.

There are a number of problems with this method as I see it. First, we have an issue of the remaining time – one third. A third of each day goes where? It gets spent doing what? Not counting for meetings (which almost always can be foreseen) there is a lot of time that is unaccounted. The spirit of scrum isn’t to account for each hour and track who does what when. However, there is almost certainly a lot of actual work that people are doing during this time that has no visibility in the iteration. Agile and Scrum DO require as much transparency and vision into the process of the organization, and this practice of “load factor” I think tends to hide some actual work that the team should be getting credit for doing.

My proposal was to use the ideal days estimates, but add sprint backlog tasks for the things that were being done “on the side” to make them visible, and get “credit” for the real work that was being done but not planned and estimated.

The flip side is that things like meetings, applying operating system patches, and answering email don’t have any real value they deliver. So in that sense, they should NOT be on the backlog. These things are accounted for in the number of available hours for “work” – actually developing the new software.

Leave the status reports and department meetings out of the backlog, but definitely put in that “extra report” for the boss or that batch script for the IT guy. Those are at the very least tasks, and they have customer value (to the customer who got them, not necessarily the end user). Estimate them with story points (even if it’s after the fact), and by all means include those points in the delivered stories at the end of the sprint.

This way there is complete transparency. Everyone can see the actual work that got done, nothing falls through the cracks. And later, when stories aren’t being delivered fast enough (according usually to the boss who got the extra report) then everyone can see that the extra half day spent on that report could have been used to deliver a story. The whole team can then really prioritize what the real features are.

Also – there are a couple of inherent problems in the scenario described above… a good scrum master would have blocked the addition of an “extra report” making the boss decide if he wanted to wait until next sprint or abnormally terminate this one… A second problem that is evident here is that perhaps the Product Owner isn’t perhaps taking into account the internal stakeholders and prioritizing accordingly. Either way, we still shouldn’t be randomizing the team by inserting unplanned work in the middle of a sprint. If it’s that important, stop and re-plan the sprint with the new priorities.

Scrum really does work, but only if we have a set of rules that keep everyone accountable for their contributions and the organizational structure in place to keep the team focused on completing and delivering the highest priority work first.