TL;DR
In your specific case, it would be best to treat the week as a drag on productivity. This won't actually affect team velocity if you don't jigger with sprint lengths; what it will do is act as a visible cost in your project's release planning by reducing the number of full-length sprints remaining in your current schedule. This is a Good Thing™ because it reflects the project's reality.
The Red Herring
Is it okay to have a sprint where the team commits to zero story points?
Yes, but your real question is something different. :)
Make the Cost Visible
The product owner prefers the team not work on any product backlog items until he can groom the backlog further. We had planned to conduct a product backlog refinement meeting, but realised that the PO's workload was too high this time around. So is there any danger in committing to zero story points but running the sprint as if it were a real sprint?
While cadence is important to agile methodologies, the importance of transparency is often overlooked. The real issue here is that delaying work while the Product Owner is unavailable is a real cost to the project, and as such should be made visible.
With that in mind, I would tell the developers to use this week as work-related free time. Let them update their workstations, read a book on a new programming language they're interested in, or otherwise get paid to do something useful to them (and their future productivity) without formalizing it.
It is important not to make this a week of busy-work. Not only is that antithetical to the self-organizing principles of agile, it is simply not good for team morale. Busy-work also creates the illusion that the team is working on product value when in fact this time (while potentially useful to the developers) is explicitly a drag on the project as a whole. This central truth needs to be firmly maintained.
Technical Debt
On any project, there are non-product tasks that need attention. CI servers need updates, SCM servers need patches, and so forth. To the extent that these things affect the team, this is a good time to work on them, but the problem is that it becomes "invisible work" because it's not prioritized on the Product Backlog.
Additionally, the overhead involved in creating a one-week sprint rather than simply waiting until the PO is back in the saddle for the standard sprint length is probably not worth it. I believe it's better to capture this lost productivity as drag on the team's velocity, and simply plan better in the future.
Good Product Owners also generally keep a few "evergreen" stories and technical-debt stories on the backlog for just such occasions. Then, when nothing else is pressing, these stories can be legitimately worked on without being unaccounted for.
Why Team-Directed Sprints Aren't Kosher
Finally, the problem with a sprint designed and run by the team without the participation of the PO are legion. Consider some of the following:
- Unless the PO has refined the backlog and is available for Sprint Planning, the chances of the team working on the correct Product Backlog Items or producing a useful increment are vastly reduced.
- The PO has a pivotal role to play in defining the Sprint Goal for each sprint. That's hard to do without his participation.
- The PO doesn't have to wait for the team to finish its artificial sprint. When he returns, he can unilaterally declare an Early Termination and a return to Sprint Planning, so any illusion of maintaining cadence is just that: an illusion.
Conclusion
The best thing to do is to turn your developers loose informally for the week. Let them work on whatever interests them, or on their professional development. While it may not advance the project directly, it will contribute to developer happiness and improve the overall effectiveness of the team in the long term, all without compromising the integrity of the Scrum process.
