A sample weekly schedule

One of the things I get asked a lot is which meetings a team should have when. The right answer is that it varies for every team, and it changes over time. Still, it can be handy for new teams to have a starting point. In that spirit, here’s a schedule that I’ve assembled based on a few different smooth-running teams:

The schedule

When What Who
Monday, 9-10a Iteration planning & kickoff All team members
Tuesday-Friday, 9:30-9:40a Stand-up meeting All team members
Tuesday, 2-4p Product stakeholder meeting Product managers, external stakeholders
Wednesday, 10a-12p Product planning Product managers
Wednesday 4-5:30p Estimation All team members
Friday, 4-4:30p Product demo All team members, external stakeholders
Friday 4:30p-5:30p Process retrospective All team members

Isn’t that a lot?

For everybody except the product managers, that’s under 5 hours of formal meetings per week. Once a team is running smoothly, I see many people doing it faster than that.

Still, it’s much better to allocate extra time for these meetings, especially at the beginning. Making an agile transition is hard enough without the stress of blowing out time boxes. Instead of squeezing the schedule down, develop the habit of looking to end meetings early. Only once you consistently end early should you shorten the schedule.

Even as scheduled, this doesn’t end up feeling like a lot. The daily stand-up should be fast-paced and energizing. The meetings that developers must attend are all at the beginning or end of the day, yielding large blocks of uninterrupted coding time. And the Monday morning and Friday afternoon meetings come at times when people are normally spinning up and winding down anyhow.

Notes and caveats

For this schedule to make sense, the team must:

  • be doing weekly iterations
  • have an on-site product manager (aka XP Customer, aka Scrum Product Owner)
  • sit all in one room
  • use lightweight artifacts (e.g., index cards, not requirements phone books)

You can divide the meetings up into three groups:

  • The iteration planning and daily stand-ups cover what we are doing now.
  • The product stakeholder, product planning, and estimation meetings figure out what we may be doing soon.
  • The product demo and process retrospective look at what we just did.

The notion is that although the team is mainly focused on what’s going on now, product managers (and sometimes designers) need to work a bit ahead, so that the team can move smoothly into the next iteration.

It’s also important to note that plenty of conversation happens outside of these times. That’s why we all sit together. Rather than trying to make a schedule that formalizes every bit of useful discussion, it’s better to schedule only the minimum number of meetings to get everybody in sync.

Feedback wanted

Does this leave you with questions or suggestions? Let me know, and I’ll cover them in a future post!


  1. Steve Bockman:

    Thanks, William. This is very helpful. Before I began doing Agile work, I wouldn’t have believed that such short iterations were possible. I wish I’d had an example schedule like this then.

    By the way, I presume that the Wednesday evening Estimation meeting is for the next iteration, right?

  2. William Pietri:

    Exactly, Steve. Doing an estimation meeting in iteration N lets the product managers properly plan iteration N + 1. And in turn, the product planning meeting prepares for estimation, while the product stakeholder meeting informs the planning.

    Early on in a transition to an Agile approach, there won’t be much of a backlog, so a lot of the stories estimated will turn up in the very next iteration. But I encourage people to quickly get to where they have a month or so of backlog.

    When that’s achieved, some of the stories estimated will still be done right away, but others may turn up a few weeks later. And some may never get built; a feature that seems like a good idea at first may not make sense once the costs are known.

  3. William Pietri:

    A couple of people have mentioned on Twitter (where you can follow me as @williampietri) that they don’t like Monday-to-Friday schedules. I’d love to hear more about why, but I can think of 3 obvious reasons I like them:

    1) People have a well-established weekly rhythm, where they ramp up, work steadily, and then wind down. That’s also the iteration cycle, so aligning them makes sense to me.

    2) I like to have my weekends 100% off. Leaving stories hanging across the weekend bugs me some. As does coming into work on Monday and trying to figure out what the heck we were doing so long ago.

    3) If you do your retrospective Friday afternoon, you can break out the beers. Not only does that go well with Fridays, but it tends to put people in a more relaxed, thoughtful mood. Beer on Wednesday mornings just doesn’t seem like as good an idea.

  4. George Dinwiddie:

    Nice work, William!

    A couple of small suggestions:

    1. Remember that these are flexible guidelines. Some people like very precise schedules. Some people are allergic to them. And sometimes other things just get in the way. Notice the needs and wants of those around you, and be willing to negotiate cheerfully. (I’m sure you do that, but I thought it worth an explicit mention.)

    2. Consider moving your iteration boundary sometime mid-week. Almost everyone makes the implicit assumption that iterations start on a Monday and end on a Friday. Of course, they line a lot of other activities up to the calendar week, also. There’s lots of issues, some subtle and some obvious:

    * For many people, first thing Monday morning is a low-energy time. They may not be thinking much about the work, yet. The weekend activities are likely to be more in mind than the work at hand.

    * People who tend to get an early start will chafe at the slow start on Mondays, waiting for a compromise time to allow “night people” to arrive. And they will get irritated when those whose circadian rhythms often make them late to a first-thing-Monday-morning meeting.

    * Likewise, on Friday afternoon people are often looking forward to activities other than work. They tend to be more distracted.

    * Many holidays in the USA are on Monday. People looking for a long weekend for a special activity often take off on Monday or Friday.

    * Other company meetings are likely to be scheduled for Mondays and Fridays also, due to the same tendency to synchronize with the calendar.

    * People have a warm-up and ramp-down time. Putting important activities at the very start and end of the week ignores this human trait, and short-changes the activity. How deeply will you retrospect when you’re disengaging from a challenging week?

    These are just some of the reasons that come readily to mind. The end result is that I highly recommend having your iteration boundaries on Tuesday, Wednesday or Thursday. They don’t even have to be on the day boundary. You can end one iteration and start another at some point in the middle of the day.

    Try it and see how it works for you. I think you may find that people approach the planning and retrospective more mindfully than when these activities are on Monday morning or Friday afternoon.

  5. William Pietri:

    Excellent points, George.

    I totally agree about flexibility. I was hesitant to write this post at all out of fear somebody would tape it to the wall and demand their team follow it. So yes, this should be adapted energetically to local conditions.

    (I should add for the rest of the readers, though, that I consider it a problem when teams are too flexible on a minute-to-minute basis about meetings times. I see an awful lot of time wasted when teams like that try to round everybody up. I’m with Yoda on this one: Either have the meeting at 10 or don’t have the meeting at 10. There is no try.)

    You’ll be happy to know that with one team, I’m currently trying a schedule that ends the iteration Wednesday at 10 am and kicks off the next one after lunch. So far, I’m not a big fan, but I’m definitely going to see how it goes for a few months. Perhaps I’ll become a convert!

  6. George Dinwiddie:

    I’d be really interested to hear your thoughts after you try the Wednesday iteration boundary for awhile.

    I agree about punctual meeting times (even though that’s hard for me). All the more reason to avoid first thing Monday morning.

    Over the weekend, I suggest leaving a single failing test (not checked in) to get you going quickly again when you come back.

    Yes, really take the weekend 100% off. Don’t dwell on unfinished work. There will always be plenty. Sometimes, however, the subconscious finds answers when you’re not consciously pursuing them.

    Beer and retrospectives might not be the best combination, anyway. Both are important, though. You can still relax and talk about what’s going on over a beer (or a shared meal, if you prefer) on Friday afternoons. That’s a Good Thing(tm), but is a little different from a retrospective.

Clicky Web Analytics