Running a sprint from Wednesday till Wednesday

Question

Currently we have three teams who start their two week sprint on Monday and end it on Friday. We have some team-members who have every Friday off. Planning sprint reviews on Thursdays or earlier is awkward, since the sprint is not yet done, or the whole Friday goes to "waste" on non functional tasks.

We want all the team members to be in the Sprint review and retrospective meetings and want to plan them at the end of the sprint. (We record Sprint review sessions for part-timers already)

Now we have figured out some possible solutions:

1. Ask team-members to take another day off. (Asking the developers to re-arange their free day is no short-term option, mainly because of complex planning of child-care.)
2. Start Monday with sprint reviews and retrospective meetings. Afterwards (after lunch) start the Sprint planning session and hope to finish on Monday. This leads to a very long "Talking" day and this might bore some and will feel ineffective.
3. Start the sprint on Wednesday and end on Tuesday.

As we are evaluating option 3, my question is: Are there teams who have experience with mid-week start and end of sprints?

• What are the pro's and con's?
• Maybe we overlooked an option?
• Any other suggestions to handle and plan sprints around availability of part-timers is welcome.

Update Found a blog post which supports that this might be a good idea, should have googled first before asking this question maybe. Still interested in your experience though.

Update 2 We have been running sprints from Wednesday till Wednesday now for a couple of iterations. I have the feeling everyone is pretty happy with it. The teams asked to plan all the meetings on Wednesday, our day looks like this:

1. 9:15 Setup meeting room and screen-cast recorders, dial-in external stakeholders
2. 9:30 Start review sessions per team
3. Start evaluation meeting after a short break.
4. Lunch
5. Start planning sessions
6. 17:00 Have a beer and snacks :)

Answer 1

Working sprints that end/start mid week is usually more effective/efficient than ending on a friday and starting on a monday for several reasons:

It makes the last minute rush to complete work more painful and less desirable for the development team (eliminates the excuse of, "hey we can finish it over the weekend).

Reduces the risk of paying weekend overtime for non-salaried employees

Tuesday/Wednesday are peak productivity days. Monday is usually a, "warming up to the work week day," and fridays are often a, "I'm not feeling too motivated, want to get the hell out of here day."

For a centralized, 9-5 team, ideally a retro/review is held on a tuesday at around 3 or 4pm and the planning is run the next day first thing in the morning (9 or 10am). Consider cancelling the normal standup you have on planning day as well and saving the team a little time.

I've employed this schedule for 4 teams over the last 2 years running 2 and 3 week iterations (they started off using monday/friday schedules. Switching definitely improved effectiveness of planning/retro's while helping the team stick to their commitments.

Answer 2

Our team switched to a mid-week sprint cycle 14 sprints ago and we love it. Our team consists of six developers (4 in main office, 2 offshore) working in two-week sprints. Our every-other-week meeting schedule is:

• Wednesday morning: Sprint Review
• Wednesday afternoon: Backlog Review (PO and SM adjust priorities, finish cards)
• Thursday morning: Sprint Planning

The activities at the start and end of a sprint are crucial to its success, so scheduling them during the peak midweek days ensures they get the focus they deserve.

It’s also great not to interrupt the boundary between sprints with a weekend. We essentially treat Wednesday as a between-sprints day — i.e. a day set aside for reflecting on the previous sprint and gearing up for the next. It’s so much better to do that when everything is fresh in people’s minds and their attention isn’t turning to the weekend. It also greatly improves the life of the PO/PM/SM. (I can’t tell you how many of my weekends in past jobs were spoiled by scrambling to finalize plans for the next sprint!)

Likewise, it’s great to have a solid week of uninterrupted work in the middle of the sprint. I've found this has a subtle beneficial effect of discouraging coding right to the end of the sprint — i.e. Friday becomes a natural target for finishing heavy-duty coding, with Monday and Tuesday reserved for code reviews, acceptance testing and deployment.

Those are pros. Cons? Haven’t found any. :-)

Answer 3

I was working with 3 teams which had mid-week start/end of the sprint. They were starting on Wednesday afternoon (17:00) with planning and finishing sprint an hour before (16:00).

Comparing to monday-friday the advantage of mid-week cycle is that there is a weekend in the middle of the sprint, when already some issues should have been discovered.

I'm far from advocating working on weekends, but as software development is mostly thinking I have experienced that some developers just thought over some issues during the weekend.

Answer 4

We've been working with that setup in our project for months now. Two week sprints start on Wednesdays and finish on Tuesdays.

PROs:

• Mondays (slow start) and Fridays (I wanna go home already) are low productivity days as WBW mentioned before
• In our country also several Mondays and Fridays are considered holidays, as mentioned in the blog post
• It's the way the other teams we work with are already working, so we can coordinate the Demos and Reviews with them when needed (common deliverables)

CONs:

• Weekly reports to management can show "too little" or "almost everything" done because progress review meetings taking place on Fridays show little progress the first Friday of the sprint. Anyway, this is a minor concern for the team, just for the SM :)

Answer 5

As others have mentioned there are some very good reasons for having sprints which start and finish mid-week. There is another reason however which I believe is the biggest motivator and I'm surprised hasn't been mentioned yet.

If your sprint ends on a Wednesday and your sprint goal is to release to live (a good goal for many reasons) then you're doing your deployments on a Tuesday or Wednesday - not a Friday when your entire time is exhausted and ready for the weekend.

Friday deployments are to be avoided but end of sprint deployments generally a good idea. Logically then your sprints shouldn't finish on Friday!

Shuffling things around means you can use the days at the end of the week (and therefore the start of the new sprint) to gather feedback and plan your new sprint.

Answer 6

Q. What do British monarchs and Sprints have in common?

A. Upon the demise of the current one the next one starts without interregnum. The Sprint is dead, long live the Sprint!

If the current Sprint ends on Friday then the next Sprint will by definition start on the same Friday**.

Full disclosure: I've only had experience of Scrum Sprints where the Review and Retro was scheduled on the Friday, Planning was scheduled on the Following Monday and the Sprints ended and started somewhere between the two (not knowing or caring exactly when). In these situations it seemed to me there was a lot of 'slack' time imposed on the around these three events. Now, I'm all for 'slack' time, I'd rather it was not imposed at certain times.

Now, if I was King of the Team, them Sprint Review would be on Wednesday morning, immediately followed by Sprint Planning (I lay on a lavish lunch, naturally). After Planning, Developers could start working on the Increment, time allowing. (I'd have a different cadence entirely for the Retro but that's another matter...)

This way, the weekends could be utilised more effectively. We may be unique (and rubbish) here but often we have some very long process that can take hours and sometimes days to run; it is best to have them finished well before the end of the Sprint. And if it looks like it will be a 'sprint-finish' (no pun intended) to the end of the Sprint then I'd rather we do it at the start of the working week when everyone is fresh off the weekend.

I'd love to hear feedback from anyone who has experimented with this.

---

** For the pedants: this assumes intervals with open endpoints. With closed endpoints, the next Sprint could end just before the last time granule on Friday, in which case the next Sprint would start at midnight on Saturday.