Iteration Scheduling

Learn about how to schedule iterations in a PS engagement.

Cadence Planning

1 week iteration

2 week iteration

Although the above pictures show a one-week and two-week sprint (aka iteration) it is assumed that iteration duration can be adjusted based on customer needs - as long as the duration stays consistent.

Generally established best practice is to not create iterations of varying durations as this prevents consistent measurement from one sprint to the next (velocity will appear skewed). Also, sprint durations between 1 week and 4 weeks are most common. This sample iteration calendar shows 2-week iterations, starting on Tuesday, accommodating various US and APAC holidays. Note that the cadence stays the same but the number of working days fluctuates based on the sample holidays. Customer company holidays, vacations, and sick time also influence the number of working days in a sprint / iteration.

Less than one week is possible if the work and coordination efforts can be optimized, more than 4 weeks is not recommended because longer sprints delay the feedback loop from working effectively and it is more like for engagement to “go dark” due to inactivity. Shorter sprints reinforce the sense of urgency and bias for action

2 week iterations are a good target duration to use unless the customer insists otherwise. For example, customers might want the GitLab engagement to follow the same iteration cadence as their own due to the integration into the customer’s status and reporting process.

Managing a Globally Dispersed Team

What do you do if you just cannot make it work? Between various stakeholders, locations, time zones, and other challenges, coordination can be difficult. Ultimately, the specific customer situation dictates what needs to be done. For example, working in different time zones might necessitate a flexible approach who works at what hours.

Time Zone Distributed

Sample Iteration Calendar

It is important to point out that certain meetings really, really, really need to be attended - iteration reviews for example demonstrate to the customer the tangible progress that has been achieved, so it is important that both GitLab and customer stakeholders attend in order to see that progress.

Part of the established cadence allows for frequent review and refinement of engagement priorities. Well understood, high priority, items bubble to the top of the priority list; and less defined items, with insufficient detail to be taken action on, drop to the bottom of the stack.

Review and refinement of the backlog allows for the dynamic reprioritization of items as the situation on the engagement adjusts.