Skip to content

Scrum process overview: schedule

May 13, 2007 by Artem

Scrum is the adaptive and flexible software development methodology. The possibility to adjust it according to the team preferences and organizational culture make Scrum implementations look differently across the organization. Some teams like packing the estimation session into a separate day, some like doing a little bit of estimation during every sprint planning; some teams have 5 minutes long sprint reviews, some have to make their reviews day long in order to let all the stakeholders express their opinions.

Scrum process schedule can and should be adjusted according to the retrospectives held. Therefore, it is not that important to start with the perfect schedule, it will anyway be adjusted. However, it can save some time if we start with something that works for many teams out there. Here a couple of more-or-less standards schedules to start with.

30 calendar days sprints

  • Day 1. Sprint planning meeting, 1st segment - 3.5 hours
  • Day 1. Sprint planning meeting, 2nd segment - 3.5 hours
  • Every working day between day 1 and day 30. Daily stand-up meeting just before lunch
  • Day 30. Sprint review meeting - 3.5 hours
  • Day 30. Sprint retrospective meeting - 3.5 hours

14 calendar days sprints

  • Day 1. Previous sprint review meeting - 2 hours
  • Day 1. Previous sprint retrospective meeting - 1.5 hours
  • Day 1. Sprint planning meeting, 1st segment - 2 hours
  • Day 1. Sprint planning meeting, 2nd segment - 2 hours
  • Every working day between day 1 and day 14. Daily stand-up meeting just before lunch
  • Day 14. Sprint review meeting - 2 hours
  • Day 14. Sprint retrospective meeting - 1.5 hours

What do you think about such schedules? Does it look like something that would work for your team? Is it really a good start to start with one of these schemes.

Comments

Looks good

May 15, 2007 by Tote (not verified), 2 years 44 weeks ago
Comment id: 161

Hi Artem,

This setup seems fine to me. However, it's also worth noting that can be even more flexible in defining the duration of a scrum project: typically it's worth defining the duration between 2-4 weeks. Not less, since a team cannot do much in less than 2 weeks. Not more, since we would lose the ability to react to changes quickly - don't forget one of the most important rules in scrum: never ever inject new requirements into a running sprint.

It's another topic, but still in connection with scrum: it's one thing that a team is committed to following scrum's rules, but it won't help if the customer doesn't understand/support that. It's the better case if they approve that we apply scrum framework, but it's still too bad if they don't fill in the role that scrum assigns to them: being the product owner. It's a pretty difficult situation, btw.

Tote

Art of possible

May 15, 2007 by Artem, 2 years 43 weeks ago
Comment id: 162

Scrum is the "Art of possible". Every team adjusts the process according to its circumstances. If team believes it can work best with 3 week iterations (though it is rarely a good choice), it can try it. I only wanted to present couple of usual "default" schedules that are good to start with.

I believe, the same goes with the customer involvement issue. If customer supports the process, it's good. If he doesn't, the team has to find out a compromise. E.g. if a customer doesn't have time for being a product owner, team can have a proxy product owner.

One-week Iterations Possible in Web Development

November 27, 2007 by Michael Dubakov (not verified), 2 years 15 weeks ago
Comment id: 1389

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters (without spaces) shown in the image.

Best of AgileSoftwareDevelopment.com