How many "making" days are there in a two-week sprint?

It's not 10 that's for sure. 

Authors note: there are a few links to supporting materials in this article, I've written it from the perspective that you will have read these articles whilst reading this one, rather than regurgitating them for you. This article is designed to be a thought provoker and conversation starter.

If you're using the maximum timeboxes that the scrum guide recommends (4hrs for planning [2hrs for actual planning and 2x1hr for refinement?], 2hrs for the Sprint Review, 2hrs for the Sprint Retrospective and 2.5hrs for all the daily scrums [10x15mins]) then you're already down to 8.5 days per sprint.

Except you're not. Studies show that there are only 3-5hrs of productive time a day; don't you sit there and roll your eyes, you know it's true for the majority of people (I definitely include myself in this). You don't need me to tell you that a day where you squeeze in the sprint review, retrospective and planning is absolutely brutal, even when you're not using the maximum timebox. I’d assert that when they are all squashed into one, the value delivered by these events greatly diminishes the longer the day goes.

That's the second time I've mentioned the maximum timeboxes; what's my deal with that???

I think you should make use of them. 2hrs for the sprint review, when you address everything suggested in the Scrum Guide with the suggested attendees is tight for time, not ample. The retrospectives you can facilitate in 2hrs can be much more engaging and productive than short sharp ones. This isn't to say that you must arbitrarily use the full allowance, but I wouldn't write it off from the get-go. I absolutely would say that a 30-minute “demo” masquerading as a Sprint Review is adding very little value.

Assuming you are using the full timeboxes then I'd go a step further, you could have the Sprint Review and Retrospective on one day and Sprint Planning at the start of the next. You could make the most of the day with the Sprint Review and Retrospective by splitting them with a team lunch and some chill time. Unwinding is good for productivity.

Now you're down to 7.5 days.

Except for the fact that you're not, of course.

I've found the observation made by Paul Graham to be absolutely true: if you have a meeting at some point in the morning or afternoon you end up writing off that half of the day (give or take). This is really important to take in to account when you also consider the number of productive working hours you might have in a day.

As you've likely got a couple of refinement sessions in there that run for about an hour each…you could realistically be down half a day of productivity per session. You could also be down even more as the Scrum Guide says you could spend up to 10% of your sprint doing refinement activities, which is a day in total.

So now you're potentially down to 6 days of time where you can sit at your desk and "get shit done" (by this I mean the work that all the events in Scrum support you in carrying out). Let's not forget that by talking about productivity, I am not talking about getting more work done (output), I'm specifically talk about "making the magic happen" (outcomes); we want to be as efficient with the time available so that we make the biggest difference we can with the time we have available.

6 days. Out of 10.

It may be more for some teams and less for others. My observations are that this is reasonably accurate, certainly enough that I want to share it with you. Have a look around in your organisation and see what you make it out to be, let me know in the comments if you’d like. This isn’t a bad thing by the way, it’s just “a thing”, something that perhaps should be acknowledged (for the sake of transparency) and worked on. At the very least I'd beg you not to flat out ignore this stuff.

For now, let's say we’re accepting this general rule; let's work out how we can adapt to make the most of the productive time we do have. Here are some suggestions you could try (all things I have trialled and had varying levels of success with, dependant on the team):

• Save all the “whole Scrum Team” conversations for one of the scheduled events when possible; prioritise the burning conversations. Most things can actually wait a few days.
• Make sure you understand the difference between the Scrum Team and Development Team with this one.
• Keep the days with no events completely free of other meetings so people aren’t disrupted.
• Sit in “team rooms” so that all of the materials and resources the team frequently need are in the same place, and there are fewer distractions.
• Do the Scrum Events properly (achieve what is described in the Scrum Guide).
• Experiment with using the full timebox available to you; is it actually more productive?
• Try different facilitation techniques for refinement and planning sessions to make them more engaging (a common complaint).
• Ensure the Sprint Review is a two way street between the Scrum Team and the stakeholders.
• Don’t be afraid of the fact that there may only be 6 days in a two-week sprint where “stuff gets built”...and even then it might only be 3-5hrs a day. Embrace it, make that time absolutely sensational.
• Understand that this applies to pretty much all the skills in a Scrum Team; everyone needs "making" time (yes, even the Scrum Master).