A question I field frequently is “When should we start and end our iterations?” For a long time, I worked on teams that started our iterations on Monday and ended them two weeks later on Friday. We did our planning meetings on Mondays, and our review, demo and retrospectives on Fridays. But, the more I think about it, the more I’m now inclined to answer that the best iteration start and end dates are midweek.
I would suggest that you start your iterations on Tuesdays or Wednesdays and end them on Wednesdays or Thursdays. The logic behind this is simple. Think about it: Monday morning, folks roll in from the weekend and are kind of groggy. They’re not 100% focused. Is this really the best time to be thinking about planning your next iteration? The planning meeting is the place for robust, intelligent conversations to happen when nailing down the details and tasking a user story. If your team is half asleep, or still getting over the weekend, this is probably not the optimal day for planning. By Tuesday or Wednesday, the team is awake and engaged, ready to think. This is probably closer to optimal for planning sessions.
On the flip side, the end of an iteration doesn’t fare very well on Fridays. First, if you have team members getting an early start on the weekend, you’re missing people for your reviews, demos and retrospectives. Not ideal. And, if you’re missing your product owner or stakeholders for your demo, definitely not ideal. But beyond that, Fridays usually present us with another case of lack-of-focus. You and your team could probably muddle through your review and demo even if you’re distracted by the impending weekend plans or tired from a long week of work. But for your retrospective, you not only want your team present physically, but mentally as well. The retrospective is possibly one of the key practices for success in agile development. A team needs to be sharp to really consider what went right during an iteration, what went wrong, and most importantly, what they need to do to improve their practices in the future. If there is a lack of focus during the retrospective, your team could be missing out on some of the best benefits agile has to offer. So, to keep things focused, I would recommend ending your iterations on either Wednesdays or Thursdays. And try to schedule the review/demo/retrospective early in the day as opposed to later in the afternoon. Not only will this help keep folks focused, it’ll also cut down on last minute coding/fixing before the demo.
Related posts:
- QA and Testing in an Agile Environment In the past few weeks I’ve been asked about and...
- The agile meeting dilemma If you’ve been doing agile, and especially Scrum, you’re...
- If scrum only had a heart I’ve heard people say that scrum teams don’t have a...
- Retrospectives: You live, you learn I recently came across a quote from one of my...
- Baby steps into agile I was watching an old movie last night that...
Related posts brought to you by Yet Another Related Posts Plugin.
47 Responses
November 10th, 2008 at 12:26 pm
Not Monday or Friday is my choice.
#1 More people take vacation days on these days, so planning can be less optimal. Mondays are also often holidays.
#2 There might be pressure to cram over the weekend to get done by Monday mornings. But that assumes you demo and plan on the same day.
Just my opinions.
November 10th, 2008 at 12:46 pm
It’s a lot easier if different teams do not start and end their iterations on the same day. Easier to get conference rooms, client attention, help from people working on other teams, if other teams do not have stard/wrap up meetings on the same day. If there is more than 2 teams, that means at least some teams will be using mid-week iteration start and stop days.
It’s also usually easier to get the entire team in during mid-week than on Monday/Friday.
November 10th, 2008 at 1:04 pm
I agree with Patrick. In my group we start on Wed and run 1-week iterations. This avoids team members missing a retrospective, demo or planning session, which all occur in mid-week.
November 10th, 2008 at 1:23 pm
Well, my team is in a geographically distributed setting and other factors, including the ones described by Patrick and Bob, contribute to choosing short week iterations in the middle of the week. In this way, the team chose Thursdays and it’s working quite well.
November 10th, 2008 at 1:31 pm
I like to kick off an iteration with a planning meeting on Monday and finish with a demo on Thursday. This way the product owner has all of Friday to digest and consolidate the feedback and to act on it. Fridays, then, are used to run retrospectives, tighten up loose ends, take care of other business not related to the current project. We’ve also found out that Friday’s are not a good fit for demos at our company because often key people who need to attend them are not around.
November 10th, 2008 at 1:42 pm
While I am not a fan of Monday and Friday meeting, I do feel it necessary to offer this devil’s advocate argument for not going to mid-week iterations. Your logic states that Mondays and Fridays are bad because the team tends to be rolling in from or rolling out to the weekend. “They’re not 100% focused.” By moving to mid-week iterations, you have moved this poor performance time in to the sweet spot of cranking out code. It would follow that the iteration speed would decrease due to the lack focus and making stupid programming errors. Additionally, the percentage of code that would be refactored over time will increase.
With that said, this could be an interesting discussion of the “Individuals and interactions over processes and tools” of the Agile Manifesto. After all, you are attempting to address how the team interacts.
November 10th, 2008 at 1:45 pm
@ Don: That’s very true and something I’ve wrestled with myself. But, I think that team interactions need to be really focused and Monday/Friday iterations seem to be less effective in providing focus at the critical planning and retrospective junctures of an iteration. But, I do agree that we ned to pay close attention to the quality of our software, whether we’re writing code on Mondays, Wednesdays, Fridays or whenever.
November 10th, 2008 at 1:48 pm
I agree with your post and have had similar experiences. We were conducting planning meetings on Friday and everyone was trying to end the meeting as soon as possible. When we switched planning meetings to Wednesday’s, the team did not feel pressure to end the session on time so people could leave for the weekend. We also did not have to contend with staff PTO which is more likely on Friday’s than a Wednesday.
November 10th, 2008 at 1:50 pm
I find Fridays a bad day to schedule (almost) ANYTHING. Part of the reason is psychological, but there are practical reasons. If a deadline is scheduled for Friday, then any slippage will drive it to Monday and thus 3 calendar days.
On the other hand, scheduling a “checkpoint” on Friday, and ensuring that “whatever it takes” to have the goal met by a Monday deadline provides both a safety factor and a real incentive.
Finally I never attempt to start the next iteration on the same day as the previous one ends [I know of some teams that do]. The benefit of being able to review the work done by others for 1-2 days is invaluable. In many cases the “fresh set of eyes” or new use cases bring to light issues which may not have been immediately noticed if the focus rolled directly into the next push.
November 10th, 2008 at 1:52 pm
Our team does 2-week sprints that start and end on Tuesdays. We plan to do our deliverable/presentation and retrospective in the morning and then do sprint planning in the afternoon. This works well because our team consists of employees and consultants and it makes it easy for us to schedule and do it all in one day.
November 10th, 2008 at 1:53 pm
I’m with you. The key point for me: No one wants to be in the office Friday afternoon and many are still asleep Monday morning. Net result I don’t plan meetings in either slot.
November 10th, 2008 at 1:56 pm
We’ve often ended on Mondays to allow the use of that last weekend to catch up if needed.
November 10th, 2008 at 1:59 pm
We used to try to schedule iterations to start on Monday and end on Friday. This was largely because we run 1 week iterations. Putting a weekend in an iteration encouraged teams to improperly load balance knowing they had a weekend to make up for any inefficiencies encountered early in an iteration.
We then had the problem of Mondays people stroll in not ready to go first thing in the morning and so planning is impacted by bad decisions. Additionally, a lot of people want to get out the door early on Friday and check out mentally about noon so demos and retrospectives started to suffer.
After a lot of thought, I think that putting an emphasis on what days to do an iteration is simply a band aid to hide something else fundamentally flawed in the team dynamic or value system. Rather than play with iteration start/stop dates we need to be addressing why performance on monday and fridays is subpar or why the team might sand bag early in an iteration and pile up work for the weekend.
We have moved to iteration start/stop days to be agile. They start when the customer is ready and end 5 business days later. If we have some form of abnormal termination or other event within a release we pick up and start a new iteration on next available day as seen fit.
Just my two cents.
November 10th, 2008 at 2:06 pm
We have a team that does Monday for start and one that does Wednesday for their start. I find the Wednesday start is easier to get the users to fniish their testing and they do not like having meetings on Mondays as they are normally very busy on that day of the week. The team cadence is much more relaxed with the mid-week start than the beginning of the week team. We have users that are on both teams so they picked different start dates so they would not have conflicts for their start and end meetings.
November 10th, 2008 at 2:18 pm
My recent client started out with reviews on Friday, followed by planning on Monday. Over time, and with lots of input from the teams, we gradually moved most teams to a Thursday planning schedule. This made sense for a few reasons, one of which, is that their releases are scheduled on Wednesday’s. Now iterations end with a release on Wednesday evening, and retrospective and planning happens on Thursday. The iteration cycle is 2 weeks long. If we find that a particular Thursday is not going to work, let’s say Thanksgiving, then we move the retrospecting and planning to the next scheduled work day.
November 10th, 2008 at 2:32 pm
I’ve only ever started mid-week… never thought of doing Monday to Friday!
Originally this started because I allowed my team to take as much time as they needed for Sprint planning, and planning would happen between not in Sprints. This meant that for the early Sprints the start day would shift through the week. At that point it was deemed better to have a properly planned Sprint than to have a fixed length planning session. Now thew teams are more used to the process we do the planning in the Sprint and attempt to keep to a timebox (fairly successfully).
My thoughts on M-F well… I think its like the reason not to do the Scrum at the beginning or end of the day. As already mentioned Monday and Friday may incur extra vacation hits but also Monday is prone to “a case of the Mondays” and also potentially catching up on weekend email etc (depends on the environment) and on Friday people are often tired and working towards the weekend.
November 10th, 2008 at 3:12 pm
I start iterations on a Wed, for the prime reason in that people naturally hate working late on fridays, and if you need to pull an extras couple hours now and again then a tuesday evening is a lot friendly than watching your weekend slowly dissolve.
Where I have more than one team on different projects we’ll start on different days, selecting Tue, Wed and Thursday so that Subject Matter Experts or shard resources ( where we can’t get them on the team ) don’t have to attend 3 end of iterations in one day.
November 10th, 2008 at 3:37 pm
I have tried various start/end days over the week across many projects.. I find the best day for starting an iteration is Tuesday. That way you still get the benefit of nearly two full interrupted weeks, as well as the benefit of not finishing on a Friday, for the reasons stated above. In addition, you have to consider the best day/time for the iteration showcase, kick-off and close meetings..
November 10th, 2008 at 4:05 pm
I find that ending an Iteration on Tuesdays or Wednesday’s is best. This at least Monday to get finish off any last items needed for the demo and to prep the demo environment for the next day. A more mature team will need very little time and can push more business value generation into Monday (higher velocity). For a less mature team this makes their weekends happier knowing that they have at least Monday to get their act together for a successful demo.
November 10th, 2008 at 4:09 pm
I agree, the mid week iteration start and end works. The reasons stated in your blog seem valid and quite applicable. Although, the end of an iteration on a Friday with a gap of a day between iterations ( with the planning mid-week ) seems to work better.
November 10th, 2008 at 4:41 pm
Tuesday or Wed works best for me. Gives the team time to complete one sprint then have enough time to get into next sprint before the week finishes. I generally try to run short sprints (e.g. 2 weeks) and this makes the start/end date even more important
November 10th, 2008 at 5:15 pm
I’ve had success with holding Review and Retrospective on Tuesday morning and then a Planning meeting. A good way to shake off the weekend and get back into it on a Monday is to realise that you have the Sprint Review etc. the next day, we found. I think Wednesdays would work well too but don’t have much empirical evidence yet to back that one up…then if you can’t face doing a Planning meeting that afternoon, you can use Thursday morning for that and avoid frivolous Friday.
November 10th, 2008 at 8:23 pm
First let me say that I don’t think one size fits all. Obviously teams need to find what works best for them. However, I’m surprised there aren’t more people chiming in about the virtues of Monday and Friday start and end dates. Starting an iteration on a Monday punctuates the beginning of the work week and doing so with commitments helps to get the entire team off to a good start and with a healthy level of urgency. Similarly, closing an iteration out with the promise of having a free weekend without any work hanging over their head is a great motivator. I find that an entire weekend free from work concerns leads to more refreshed teams ready for the next challenge. When you use mid-week start/end dates the team never has a weekend that’s truly their own because there’s always some work in progress to occupy people’s minds.
November 11th, 2008 at 12:26 am
I personally have very good experiences with 2 week sprints, starting on mondays and ending on fridays.
We aim at finishing the sprint at noon on the last friday, after which the team has time to prepare for the demo, but also, to for example optimize tests or even to go home early.
This gives the team a little bit of recovery time before the next sprint starts.
The next monday, we first do the last sprints demo, retrospective and the next sprint planning, which consume most of that day.
This way, in every sprint we have two four-day periods of uninterrupted sprint time, which, I feel, has a positive effect on the team’s velocity.
November 11th, 2008 at 5:11 am
People are saying that you should avoid Mondays and Fridays because the team is less productive on those days, but that means the team will be doing production work on those less-productive days. If planning an retrospectives are done on Mondays and Fridays then because the Scrum Master is chairing those meetings won’t he be able to keep people on ball?
November 11th, 2008 at 5:47 am
Tuesday or Wednesday for me as well. I agree with the above comments but another reason for avoiding a start/finish on a Friday/Monday is that public holidays tend to fall on these days
November 11th, 2008 at 6:43 am
I have had experience with both situations. From my perspective, I’ve preferred to end on a Friday and go into the weekend with a free mind. However, the feedback from many teams I’ve worked with has not been consistent with that. I have seen two specific situations with iterations not ending at the end of a week.
End on a Thursday, and do planning on Friday. Work would end Thursday EOD and we would do our iteration retrospective Friday morning, put together a plan in the afternoon and then people would have the weekend to think about the work and be ready to start first thing Monday morning. This was also good when some people would come in earlier than others. It also reduced the chance that someone snuck something in at the very last minute before going home for the weekend.
End on a Monday, do planning on Tuesday. I think this model was slightly less effective, but it was done to accommodate a number of interdependent teams and to ensure that the iterations always ended on the same day (Fridays and Mondays were challenges due to holidays). My impression is that this broke up the rhythm just a little too much, but to be fair this was a team very new to Agile and they had other struggles well beyond when they began their iterations.
I can certainly see your points on your blog against putting too much important work on a Monday or Friday. The only counter I would have to that is that many developers I’ve worked with have indicated that retrospectives and planning are a very different type of work and sometimes a nice change of pace on a Friday. I think this is one of those things in which there is no right or wrong answer. In fact, this is the ideal thing to discuss in a retrospective and let the team decide based on their own preferences and work habits.
November 11th, 2008 at 7:13 am
Duncan, to my mind the big thing is not so much the distraction (though that is an issue ) as the unavailability of folks, I was just chipping in some extra thoughts.
The main downside of a M-F thing type cycle is that if you are going to make mandatory meetings (which Scrum really requires) it kills people’s ability to have vacation on those days. If you don’t make them mandatory then vacation can get in the way and team members can be missing from these crucial meetings. This problem is less severe if you have longer Sprints.
Scrum master keeping the team on the ball…. my experience…. works about 80% - like herding cats
My current teams start and finish the (2 week) Sprints on a Thursday.
November 11th, 2008 at 7:49 am
We currently work in one week iterations that start/end on Tuesdays. We do our weekly demo Tuesday morning, and then iteration planning after that. It has been working really well. We used to do that Monday morning and ran into many of the issues described above - Monday holidays, vacations, playing email catchup, trying to remember what we were working on the previous Friday, etc.
November 11th, 2008 at 8:04 am
I really like the mid-week iteration concept. But in real world we have holidays which change the start and end dates. What is the best practice in dealing with holidays?
November 11th, 2008 at 8:43 am
I prefer mid-week start/ends because it is more important that people are present and engaged during the start/end activities. Mondays/Fridays tend to get clipped by holidays and long weekends more often than other days, and people are catching up on Monday and checking out on Fridays. (I’m talking more about the business voices than the development team).
A successful sprint begin/end is dependent on an energetic and focused product owner or customer. I have found it’s easier to adjust velocity and planning for holiday or resource gaps in the middle of the sprint than move the sprint boundaries.
That being said, Brian’s point about going home for the weekend with a clear plate is something a lot of people prefer. So, I think the team needs to evolve this to match their culture and needs (just like sprint length).
November 11th, 2008 at 9:17 am
I prefer to do demos on Friday mornings, retrospectives and sprint planning on Friday afternoons. Get back to work on Monday, fresh and ready.
I think people tend to take iteration length too seriously. The ACTUAL point to structured length iterations is to be able to accurately manage workload and estimates. But as we all know, sprints are rarely cookie cutter. Once you have good estimates (# days * ideal hours per day * team members) simply substitute out X if something jumps in the middle. If your three week sprint has a holiday in the middle, simply subtract out that time of your planned throughput estimate.
November 11th, 2008 at 11:04 am
We do one week iterations. When the project first got going, we started sprints on a Monday and ended on Friday, which seemed like a logical choice. What we found is the end of the sprint can be the lowest energy level for the team. If you tack on the weekend, it takes even more energy to get going again. Now we start on Wednesday, and it seems to work better. We have the momentum of the previous sprint going into the next one. Although the weekend breaks up the sprint, it gives team members some thinking time to reflect on the work they are doing.
November 11th, 2008 at 12:14 pm
We prefer mid-week: Friday as demo day means invariably that if some urgent pressing thing arises from a demo, it puts pressure on people to work over the weekend.
Second, if you also go live at the end of each iteration, you could end up with some go-live panic, which nobody wants on a Friday night
Lastly, people are more switched on mid-week than dreary Mondays and less distracted than on Fridays where the prospect of a weekend off is on the horizon.
Our weekly demo is Tuesday night, go live is later the same night, Retro and planning on Wednesday morning.
November 11th, 2008 at 1:43 pm
We do one week iterations as well. When we first got going, we started sprints on a Monday and ended on Friday. What we found is the end of the sprint can be the lowest energy level for the team. If you add a weekend in after that, it takes even more energy to get going again. Now we start on Wednesday, and it seems to work better. We have the momentum of the previous sprint going into the next sprint. Although the weekend breaks up the cycle, it gives team members some thinking time to reflect on the work they are doing.
November 11th, 2008 at 1:51 pm
I also think that starting a sprint on Monday and ending on Friday is not such a good idea. Starting and ending mid-week is best. I also think that doing sprint planning meetings on Fridays could also be an issue since most of the devs tend to leave earlier or be on holiday on Fridays. On the other hand if they want to leave early from work they will be much faster at estimating. :).
November 11th, 2008 at 4:11 pm
We end our iterations on Wednesday afternoons, do our retros and planning then, and begin work Thursday mornings. Even though our iterations are only one week long, we still do a scrum-of-scrums on Monday afternoons to identify and address any risk.
We were ending on Friday afternoons and starting Mondays, but for some reason, that caused a lot of thrashing getting to the 1:00 Friday demo. Somehow, demoing on Wednesday’s @ 1:00 seems much better. And, attendance is much better mid-week as well.
November 11th, 2008 at 4:53 pm
I usually start the first day we are ready to start planning and that becomes our cycle. Cannot say any day of the week seems to work best. I do like having the review/retro and then into planning the next day so that would eliminate a friday/monday cycle.
November 11th, 2008 at 6:05 pm
Another reason to not end on Friday: too much temptation to slip in that last thing over the weekend, which ends up breaking the build / breaking the system for the demo / etc. Too much scrambling ensued.
November 11th, 2008 at 7:59 pm
We have two week sprints, ending with demo and retrospective on Tuesday morning, with the next sprint’s planning session on Wednesday morning.
We considered sprint planning in the afternoon of the demo and retrospective, but ruled it out for two reasons;
1 - reserving Tuesday afternoons for non-sprint work (in a nod to ‘google days’) allowed the team to persue non core tasks or pet projects which are personally rewarding and motivating (not to mention usually benefit the project like improvements to our build engine.)
2 - the team is split between North America, and Europe; our European teammates really prefer to not be in the office until 10 PM.
Also for good stretches of the summer months, differing statutory holidays and vacation days used to extend the weekends would invariably mean 1/2 the team was unavailable on either Friday or Monday anyways.
But like the posters to your blog post point out, the big detraction we found for Friday/Mondays were
1 - everyone rushes to get out as soon as possible on Friday
2 - noone really checks in on Mondays until after noon
November 12th, 2008 at 5:20 am
Hi,
Start iteration on Tuesday or Wendesday is seemed to work best.
If an iteration starts on Monday, the end of previeous one is “too far behind” ( a week-end in between can change a lot). In the same way, ending iterations on Friday puts too much pression on the team.
We’ve done retrospectives either before or after the review and planning game.
As for myself, The formula I like best is review, reprospective, planning game.
Best.
November 12th, 2008 at 6:27 am
We usually follow monthly cycles, so 1 of the month is the start for new sprint. The demo and retrospective gets done in the last 2 days of the month. Few team complete the re planning rest of the project too and from on 1 of the month complete the iteration task details and planning. For a fortnightly sprints guess a Tuesday/Wednesday planning makes sense.
On one project that we did fortnightly, I fount it better to have a sprint for 10 working days and then 1 day for demo and 1 day for re-planning/buffer. So there is not one start fixed day. it shifts from sprint to sprint. only constant is once started the sprint needs to end in 10 working days. Iteration planning is part of sprint, demo is not.
November 12th, 2008 at 3:45 pm
Currently my team runs 1 week iterations (5 business days) with 2 slack days in between the end of the iteration and the beginning of the next. The fast pace works very well because it allows for the business to change the direction of the team very quickly. We have our iteration planning meeting during our slack days. We have really adopted a Plan, Do, Check, Act methodology that works very well and as a result it does not matter what day of the week we start or end our iteration on. The planning of work is never ending and even after we have finalized our iteration we continue to plan during the currently running iteration.
November 13th, 2008 at 4:39 am
I’ve scheduled iterations/sprints (we run two week iterations) to start on Wednesdays for years. While it can be tempting to use the natural cadence of the week, it’s more beneficial to avoid Fridays and Mondays. For some unknown reason, those two days are the most popular days for vacations, sickness, and holidays. Plus I think teams can lose momentum from one iteration to the next by waiting a weekend.
Instead we put the finishing touches on a release Tuesday afternoon, review Wednesday morning, and plan the next iteration that afternoon. Retrospectives are usually scheduled for the next day to let the dust settle and avoid spending an entire day in meetings.
November 13th, 2008 at 5:23 am
Hi all,
Due to constraint of our customer, we are ending iteration on tuesday and start on wednesday. In fact, I use that to stop pure development on friday the week before and do last regression testing and refactoring on Monday. Then a complete Tuesday is for demo and retrospective. It provides the team a kind of small boxed time of 2 days to achieve iteration.
November 16th, 2008 at 1:35 pm
We do Monday to Friday cycles on just about everything however I am not a big fan of them. There’s an assumption inherent in a Mon to Fri cycle that people are on the ball and as motivated every day of the week whereas I think that most people are less motivated Monday and Friday compared to the middle 2 days. Certainly I am. I’d rather have the Friday and the following Monday in the middle of an activity, what ever it is, and have the important kick off and end stages mid week.
November 17th, 2008 at 3:49 pm
Our two week iteration/spint schedule starts on a Wednesday and finishes on a Tuesday with our Demo/Retrospectives. We did this because starting and finishing mid-week helps lesson the impact from holidays, vacations, illness, etc.
Leave a Comment