Preferred Two Week Scrum Sprint Schedule

When teams are new to agile scrum, they find it difficult to organize their work to best meet their Story Point commitment in a two week sprint. I’m all about organizing for success, so I decided to share my personal best practice Sprint Schedule.

Daily Standup is Best Held in Morning

A best practice is to hold the Daily Standup in the morning. That way, everyone on the team presents their status, next steps and blockers at the beginning of the work day. Issues are raised and plans of action are devised with the entire day available to execute corrective action. Team members who floundered yesterday, can get the help they need from their teammates early in the day and get their Stories back on track. The Scrum Master has all day to remove any new roadblocks.

Week One – Focus on Burn Down

The goal for the first week is to close the highest priority Stories. Starting the Sprint with a healthy Burndown (refer to my earlier post on Burndown Charts) keeps the team from going off a cliff at the end of the Sprint, rushing to close their Stories at the last minute.

While the Development Team is closing Stories, the Product Owner and Business Analyst should meet with the customer to demo the features completed in the prior Sprint. This gives the customer a chance to provide feedback on recently completed features, and gives the Product Owner assurances that the completed features meet the customer’s needs.

Depending on the feedback, the Product Owner may need the Development Team to pivot slightly or make a few changes in the next Sprint. By demonstrating for the customer early and often, the customer can better envision the completed product. Any requested changes should be small, so the project can remain on schedule.

After receiving feedback, the Product Owner can re-prioritize the Backlog and work with the Business Analyst to write missing high-priority Stories needed for next Sprint.

Major changes or new functionality requests by the customer should go through change control for approval. Even though the team is agile, they are still working on a budget and must deliver according to their release schedule.

A typical Week One schedule looks like:

• Day 1 Mon – Sprint Planning
• Day 2 Tue – Customer Demo and Feedback on last Sprint’s Stories
• Day 3 through Day 5 (Wed through Fri) – Close Stories and Build Backlog

Week Two – Prep for Next Sprint

The goal for the second week is to continue closing Stories and prep for next Sprint Planning. At Standup on Monday of the second week, take a hard look at the Burndown Chart and Sprint Backlog. Has the team closed 50% of its Stories? If not, quickly assess root causes and work with the team to make a plan for corrective action. Remember, life is not linear. There is still time to meet all Sprint commitments.

The beginning of the week is also time for the Product Owner to review all the new Stories written last week and reprioritize them against the existing Backlog. Tuesday is a good day to reprioritize the Backlog and identify the highest priority Stories for grooming and estimating. Don’t let the Product Owner wait and perform this task during the Story Grooming meeting.

Mid-week is the best time to groom and estimate Stories. Insights gained during Story grooming and sizing provide the Product Owner with additional knowledge with which to reassess the Backlog one last time before Sprint Planning.

Conduct the Retrospective and Team Demo on the last day of the Sprint. Celebrate wins. We recommend providing refreshments and snacks. This puts everyone on the team in a good frame of mind to discuss process improvements.

A typical Week Two schedule looks like:

• Day 6 Mon – Assess Sprint Status
• Day 7 Tue – Continue to close Stories and Prioritize Backlog for Grooming
• Day 8 Wed – Story Grooming and Story Point Estimating
• Day 9 Thu – Re-prioritize Backlog
• Day 10 Fri – Team Demo and Retrospective

Alternative to Team Demo during Retrospective

To minimize meeting length on Retrospective day, several teams I’ve worked with have opted to include Team Demo as part of their Definition of Done (DoD). This means team members working on a Story must Demo it after Quality Assurance (QA) tested in order for the Story to be eligible for closure.

To keep the post short, I only discuss the scheduling of Sprint activities and not their definition or best practices. For those readers new to agile scrum, I recommend you read our GSD Scrum Handbook. It’s talks about the GSD Scrum Method for practicing agile scrum in more detail.

Focus and coordination of small sets of activities is the key to organizing and managing a successful sprint.

Let me know if there is anything else I can help you with,

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500