Skip to main content

Calendar Question

Last post 07:43 pm February 21, 2020 by James Noble
14 replies
08:20 pm February 20, 2020

Myself and a coworker are new Scrum masters and work with 3.5 (.5 DevOps) teams. Needless to say we've been learning a lot on the job.



The team has agreed to change the calendar to follow the Scrum framework.

 

  1. Currently the Monday in the last week of the sprint there is planning.



    a.  We've changed planning to occur on the first day of the sprint.



    Note: We are doing every other (Individual Team Retros and Planning for one sprint, then Whole Team Retro and Planning for another).





    Issue: The sprint when there is a whole team planning we are not sure how to plan for the teams.



    Do I:

    1. Propose to the team we remove the whole team planning and stick to the individual planning?

    2. Move planning to the last day of the sprint and have the retros on the first day?

     (our sprint ends on Thursdays)



    Thank you in advance 

10:08 pm February 20, 2020

Sorry, I am having a hard time following you. What do you mean by whole team planning vs individual planning?

Why would you have planning on the last day of a Sprint?

 

 


02:59 am February 21, 2020

Myself and a coworker are new Scrum masters and work with 3.5 (.5 DevOps) teams. Needless to say we've been learning a lot on the job.

The team has agreed to change the calendar to follow the Scrum framework.

Which of the 3.5 teams are you talking about, and how does half a team make a team at all?


07:13 am February 21, 2020

Besides the very valid questions above, I would not recommend doing planning before going into the Sprint Retro etc, as at least one item is placed on the Sprint Backlog that comes out of the Sprint Retro. Let say for the sake of argument that it is a relatively tough item that might need a decent amount of effort to work on, and this is not taking into account during the Sprint Planning, you have no room anymore to work on the improvement (placing in the next Sprint Planning is not an option).


08:51 am February 21, 2020

Sprint should always begin and end midweek e.g. Tuesday, Wednesday or Thursday, only.

Planning should happen during the current Sprint for the next Sprint, the next Sprint will start immediately after the current Sprint ends so it must already be in place e.g. Tuesday will be final day to plan Next, Current Sprint finishes on Wednesday.

All of the development team should be involved in the estimation and planning. If you have a large team then it can make more sense for the stories to be fleshed out by an individual developer before bringing in the whole team later. 


09:21 am February 21, 2020

Sprint should always begin and end midweek e.g. Tuesday, Wednesday or Thursday, only.

Planning should happen during the current Sprint for the next Sprint, the next Sprint will start immediately after the current Sprint ends so it must already be in place e.g. Tuesday will be final day to plan Next, Current Sprint finishes on Wednesday.

Where in the Scrum Guide does it even remotely suggest any kind of day to start or end?

The Sprint ends immediatly after the conclusion of the current Sprint, which would after what event? 


09:32 am February 21, 2020

Scrum Guide is only a guide, this is a real life recommendation. 

People tend to take vacation time on Fridays and Mondays, psychologically not finishing a Sprint on a Friday tends to mean work is not left until end of week to complete.

Sprint ends on a date. Planning for next Sprint should happen before that date. Retro and Review should happen before planning. So the final day of Sprint is very very busy, because of this in real life you should have to next Sprint more a less planned before the final day of Sprint and then finalize on the final day based on feedback from Review and Retro.

 


09:36 am February 21, 2020

What if we would have the Sprint Review and Sprint Retrospective on Fridays and the Sprint Planning on Mondays?  By all means not saying this is the best scenario (although it might for some teams), but Reviews and Retro's tend to be very heavy on the mind. Especially when hard discussions have occured. This leaves the people involved with the weekend to relieve the mind and de-stress and start fresh on Mondays. 

Just A scenario. Based on real life.


09:54 am February 21, 2020

That may work but definitely in Europe people tend to take long weekends vacation Friday, Saturday, Sunday, Monday especially during the summer months. 

I try my best to keep all ceremonies between Tuesday and Thursday and also in the AM #nomeetingfridays :)

 


12:57 pm February 21, 2020

@Niall Fallon I think you have a lot of useful insights, but I've noticed you're very forthright with some of your assertions. I think that can trigger a useful debate, but it also disregards a lot of the nuance in mastering Scrum.

Just a recommendation, but you might want to be less prescriptive in some of the things you say, because there's often not one universal right answer, and the Scrum Guide is deliberately non-prescriptive about a lot of matters, so that teams and organizations find the way that works for them.

 

At my company we chose to have Sprint Reviews on Tuesdays at 3:30pm for our Amsterdam office (where the Scrum Teams are based), so that our colleagues (stakeholders) in New York are also able to attend.

The timing means that we cannot hold our Sprint Retrospectives until the next morning, and Sprint Planning begins late morning, after the retrospective.

We ruled out having the Sprint Review on a Friday, partly because of general staff availability (e.g. holidays, or company-wide meetings), but also because we considered waiting all weekend for a retrospective to be wasteful.

As such, we then had a choice of several days. Our initial preference as a Product-Engineering team was Wednesday, but we opted for Tuesday, based on the availability of other internal stakeholders.

This isn't universally popular. I received feedback from one developer that this does not allow them to switch off in the same way at the weekend as when a week would end with a Sprint Review. I take that seriously, but I feel on balance we have taken the right decision for our context.


03:11 pm February 21, 2020

Sprint ends on a date. Planning for next Sprint should happen before that date.

@ Niall Fallon Why is that? Whay can't you start a sprint with the Sprint Planning event?

Just A scenario. Based on real life.

This is what I have experienced as a very useful scenario on my previous job


04:28 pm February 21, 2020

Going back to the original post.  I'm going to make an assumption based on the phrasing you used.

My assumption:

  • When you say individual I am assuming that to mean 1 person and not 1 team.
    • This is because you say there are 3.5 teams and use team in your text.  Since you never said "all teams" I am assuming that you do not have all 3.5 teams plan/retro together.
    • You also asked how how to plan for the teams when there is an all team retro.  That makes me think you are having difficulty fitting 3.5 sets of events on the same day.

Since your question is only about Sprint Planning I'm going to suggest that you read the Scrum Guide's section on Sprint Planning. If you read that I believe you will understand that Planning is a team event and isn't done individually.  The entire Scrum Team (Product Owner, Development Team and Scrum Master) are participants but the focus is for the Development Team to forecast a body of work for their next iteraton. There are no individual Scrum events so if you do want to follow Scrum the team should stop all of the individual events.  That does not mean that individuals should be looking at the Product Backlog and familiarizing themselves with it.  That does not mean that an individual can't retrospect over the last Sprint for opportunities that the team can use to improve. That does not mean that an individual can not work on specific tasks/stories on their own.  But it DOES MEAN that any of those individual activities I just mentioned need to be shared with the team to contribute as a group to the outcomes of the team. 

Scrum is a framework that enables TEAMS to be agile and have the ability to constantly inspect information, adapt their activities as needed with the ultimate goal of incrementally delivering the value the stakeholders want at the time that they need it. 


05:43 pm February 21, 2020

People tend to take vacation time on Fridays and Mondays, psychologically not finishing a Sprint on a Friday tends to mean work is not left until end of week to complete.

@Niall Fallon, People can take a vacation any day they want. The goal of Sprint Planning is to make a forecast given all those variables which could include holidays, weekends, planned and unplanned absences. The goal is to take on enough work that can be realized into a "Done" Increment given the available time and talent on the Development Team.

I was also told this same logic long ago but now that I reflect over it, the reason is simple, the people who advocated for that just couldn't accept a decrease in velocity/story points. I quite vividly remember one of the agile coaches or managers saying "We cannot have a Sprint with that low a velocity". For example, when a full team of 10 Development Team members on an average can complete 50 points/ 2 weeks, is the expectation that a very low staffed say Development Team with only 3 members present due to holidays or absences expected to deliver a similar velocity? or do you Inspect & Adapt with what you have on hand?

Sprint ends on a date. Planning for next Sprint should happen before that date

The Sprint is a container event. All other events cease to exist when the time-box of the Sprint ends. Period. Now, I know that is easy to say and hard to implement, especially with distributed teams in other geographies. What I also realized is that part of the problem is the heavy dependence on processes and tools like JIRA or Version One. We tend to be slaves to those than creatively addressing the situation.

I know it is very easy to say what the Scrum Guide says but very very hard to implement however, that is the point. If you've ever played the game Mario on a Nintendo, do you adjust the outcomes, the time limit, the characteristics or the challenges each level poses based on what is realistically achievable? or do you keep playing till you can conquer it, each time trying different things until you succeed?


07:26 pm February 21, 2020

 If you've ever played the game Mario on a Nintendo, do you adjust the outcomes, the time limit, the characteristics or the challenges each level poses based on what is realistically achievable? or do you keep playing till you can conquer it, each time trying different things until you succeed?

Full disclaimer Steve Matthew, I am stealing your analogy.   Thank you!


07:43 pm February 21, 2020

The current teams I am working with as Scrum Master/Agile coach end their sprints with Sprint Review and Sprint Retrospectives on Friday. They then kick-off their next sprint with sprint planning on Monday (or occasionally Tuesday if a mandatory holiday occurs on the Monday). One of the interesting wrinkles is that the teams are remotely distributed crossing three time zones so that makes more a brief gap between sprint retrospective and sprint planning.

Lots of great points mentioned in this thread. Thank-you to all who shared.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.