Scrum team members know that things get very busy near the end of an iteration. The coding and quality activities need to be wrapped up, demo preparation occurs, the sprint review is held, the sprint retrospective is held, and the next sprint planning meeting is held.
If the onsite team team prefers to end iterations on Friday, they might naturally assume they have all day Friday until evening for these activities.
However, look at what that would do to a remote sub-team in India – it would mean working until early hours on Saturday morning. A better practice is to split the end of sprint activities across two days, ideally during the overlap time dedicated for sub-team synchronization. This insures minimal impact to normal working hours at the end of each sprint.
It is even more ideal if some of the end-of-sprint activities can be grouped and run back to back during the overlap period. Sprint review and next sprint pre-planning can be done during overlapping hours. Then teams can do retros during their core hours.
Backlog grooming or backlog refinement meeting becomes a must for distributed team. Since you have very less overlapping hours, you need sufficient preparation before hand to finish sprint planning meeting on time.
Ending on Friday is not what I suggest for co-located teams too. You could read my earlier post “When is a Good Day to Start a Sprint?” to know more on this.
If Friday is working for you, they don’t need to change. Points I have mentioned here and in my earlier article are inputs to the team and possible anti-patterns team would observe. At the end decision making is with the team to find what works best for them.
Dear Avienaash,
I am agree with you that our sprint should not end on Weekends. But to overcome this problem, we can put few days break in between two sprints like sprint lags that we can utilize for all the sprint ceremonial activities like Sprint review/demo, Sprint retrospective meeting and Sprint planning and these activities can be done in 3-5 days of duration, like instead of 4 weeks of development sprint, we can have 3 weeks of development sprint and 1 week of sprint lag.
During this 1 week of sprint lag, we can even utilize for bug fixing that we are unable to fix due to time crunch or any other issues like received bug in the end of last day of the sprint.
You are right Avienaash. Friday releases end in burdening the teams. This also applies to traditional SDLC projects.
True. In 2-3 weeks sprints, this starts happening quite frequently and then team gets burnt out early.
I completely disagree with you in regards to your comment about this logic applying to traditional SDLC projects.
I would firstly like to point out, I don’t believe the sprint should be completed EOD Friday (there is certain risk involved in doing so), however I wrapping it up by mid to late morning for me is desired, having then the rest of the afternoon to monitor the sprints work. I don’t like ending a sprint mid week and the having the sprint interrupted by the weekend. I find the team gets in Monday morning having to pick up where they left off, or even worse burnt out because they were working over the weekend. It’s always nice to begin the week, where we have the opportunity…”fresh”.
Scott, even I am not sure how it applies to SDLC projects. But I will let Prabhaker Panditi to explain his stand.
I hear your point of something fresh you want to pick when you start a week. I would weigh this against other things I have mentioned in my earlier post http://www.agilebuddha.com/agile/when-is-a-good-day-to-start-a-sprint/
It is very specific to the teams and you often see this issue on many teams.
Most important thing, people get freedom to take long weekends as they would not miss Sprint Review, Retro and Sprint Planning which are important Scrum team ceremonies where we want everyone on team to be there.
Lot of Public Holidays falling on Monday or Friday would not disrupt the team much. Sometimes it becomes tough to change stakeholders/users calendar to adjust for public holidays.
Hence moving away from Friday, I have seen less disruptions.
Thanks,
Avie
I understand majority of public holidays fall on a Monday or Friday, however this if anything supports the point I am making…If the public holiday is on a Monday I would much rather start a sprint on the Tuesday than to disrupt the team in the middle of a sprint. Good forward planning and communication ensures starting a sprint on a Tuesday or ending a sprint on a Thursday…is not hindering the performance of the team.
Having a weekend in the middle of a sprint, means the team gets in Monday morning and has to spend the next couple of hours trying to remember where they left off on the Friday. In fact, if I had a penny for the amount of times throughout my career in Monday morning scrums, that I heard “Hmm, let me think about what I did Friday” or “I can’t really remember what I did Friday”….I would be a rich man.
Scott,
If Friday works for you, then there is no need to change. Every approach has its drawbacks. You will weigh what is of more advantage to you and choose with it. But I will not change by sprint start days and end days with every sprint to accommodate holidays etc. I will choose a right day and stick with it for long.
Thanks,
Avie
My point is not entire sprint being busy, but only last few days. A break in between sprints becomes tough to justify. If I take your suggestion, than rather I would think why team requires this extra few days every-time to finish sprint goals. This should become a topic of discussion for retro.
Dear Avienaash,
I am not saying break in Sprint, I am saying we have 4 week sprint out of that 3 week we consider as development sprint and one week will be consider for other activities that include Bug Fixing and other sprint ceremonies like sprint review, retro meeting and sprint planning meeting. This one week we can also utilize for product backlog grooming also.
Also benefit of this 1 week other activity in sprint help development team to concentrate only on development and no need to worry of Bug fixing, as they have some day available after 3 weeks of development.
So, using this 4 week sprint breakup, I don’t think any body have any issue and I am following this process from more than 2 years in my projects.
Great if it is working for you. I would try optimize this and see why after so many days team still need 1 week to fix bugs. Why bugs are coming at the first place, how could I minimize bugs as I know I can’t totally stop it from coming. That would be ideal or goal we all we will be striving for.
Teams have followed good XP practices to be able to finish everything within 2 or 3 weeks sprint time. Just a food for thought for you.
Thanks,
Avie.
I would agree that the options you suggest here should be taken into consideration by the team. But in the end, promote the principles of self-organizing teams and let the team determine the best schedule for their Scrum ceremonies.
These are inputs to the team to decide and possible anti-patterns team would observe. At the end decision making is with the team to find what works best for them.
Although I agree with not ending the iteration on a Friday, I don’t agree with the reasons. The problems stated in the blog post show a larger malice and by moving the sprint end to a day other than Friday , you are just fixing the symptoms.
1. “Scrum team members know that things get very busy near the end of an iteration.” <– Thats the first problem according to me. Sounds like a team rushing to a deadline. A good agile team would be delivering at a consistent pace and not waiting for end of iteration to wrap things up
2. "If the onsite team team prefers to end iterations on Friday, they might naturally assume they have all day Friday until evening for these activities." <– Why would they assume that? I am sure most onsite teams know that during their day time its night in India. And even if your scrum ends on a wednesday, in such scenario the team will end up working till Thursday morning
3. Overall it seems that the problem of "giving finishing touches on the last day" is the root cause
I agree one shouldn't end iteration on Friday because
– Many team members might have travel plans over the weekends and may have non-predictable out times on a friday
– Many conferences, dev events, meetups happen on weekend. People might want to take time off on Friday
– Large number of people tend to take Friday offs for longer weekends
– Monday starts are often delayed starts for the day
Jayram,
None of the post by itself is a complete solution. You need to do root cause analysis to find actual issue. But what I have mentioned here is, this could be one of the issue when you dissect larger malice. You may find many other problems too. This is one of the good practice followed by team. Many teams are ending on Friday and they are not facing any such issue.
Good Agile team is a goal or state we are striving for. You will face such and many other issues on your way.
Point 2: True nowadays many teams do understand there is a team on other side of the globe too who are working with us. I am afraid to say, there are still many teams where I don’t hear or see this happening.
Point 3: Root cause is not unable to give finishing touches. It is a manifestation of a problem team is facing. Unable to finish by end of sprint can happen even if your sprint ends on say Wednesday. We need to find root cause for this. I blogged about this some time ago on how to use 5 WHY’s technique to do this RCA.http://www.agilebuddha.com/agile/5-whys-sprint-failed-team-did-not-deliver-committed-work/
Thanks for chiming in here.
Avie
The point I made about SDLC is in regard to “releases”. Regardless of the approach followed, a release is a release and usually involves a host of activities. Surprises may always be around the corner. As Hofstadter’s law reminds us, “an activity always takes longer than planned, even when you take Hofstadter’s law into account.” And release activities spill over to the weekend.