It is quite challenging to prepare the backlog for the next sprint. Product Owner needs to talk and align requirements of multiple stakeholders which is not easy. Every stakeholder has its own priorities that influence other stakeholders’ plans. The Product Owner is therefore in constant conflict.

Great Product Owner always works in multiple timezones. Longterm, midterm and shorterm as well.

Agile teams need to have one prioritized list of requirements for the sprint so they can focus on quality while the priority, an order, is set by the business. These principles allow everybody in the company to deliver the most valuable and needed requirements in a very short time.

Even if it is not suggested by the Scrum framework directly, many agile teams found sprint preparation, sprint preplanning, very valuable. This meeting enables the business and stakeholders to focus on prioritization and preparation of requirements far advance before the sprint planning session. Such an investment into the preparation (continuous preparation) of requirements leads to:

• Very clear description and understanding of requirements.
• Requirements readiness can be checked before the sprint planning session.
• A team can realize if requirements are doable before the planning.
• Product Owner has more time for appropriate preparation.
• Dependencies can be discussed upfront and aligned before the sprint planning. The team will not be blocked by missing the support of other necessary teams.

Sprint preplanning

How often?

Some teams prefer to have one sprint preplanning session per sprint. We observed teams that organized more such sessions in the sprint. In the first session, PO+Architect+UX met stakeholders and they agree on a scope for the next sprint. In the second week, the sprint preplanning session has been held with team members where they discussed the doability of the proposed sprint backlog, marked items as ready, and sometimes even estimated an effort with story points.

The number of preplanning sessions and who participates depends on the complexity of the product, business, and dependencies on other development teams creating larger systems.

An example of sprint preplanning sessions (three weeks sprint, the complex system developed for multiple business stakeholders and multiple development teams):

1. The first session in the first week
   1. Session with stakeholders
   2. Every stakeholder brings its own requirements, however, they already should be ordered.
   3. Architects bring technical requirements which need to be considered as well.
   4. Stakeholders present their goals
   5. Then they agree on the mixed order.
   6. The product Owner considers this order and starts to gather details before the next sprint planning session.
2. The second session in the second week (PO + team)
   1. The product owner contacts team members to validate the readiness of requirements.
   2. Readiness is indicated by the Readiness flag:
      1. Red – the requirement is not ready for development. Additional details are necessary, or hardware devices are necessary. The team can’t continue with it.
      2. Orange – team can start with work, however additional details still need to be provided before the sprint planning session
      3. Green – ready for development
      4. Stakeholders should be informed immediately about the readiness of requirements. They should provide additional details if necessary and validate that with the team with help of ScrumMaster.
3. 3rd session in the 3rd week
   1. Stakeholders consider the readiness of requirements.
   2. Changes are considered as well.
   3. The final order of requirements is set.
   4. Requirements are updated in an electronic tool for the next planning session.

How long?

The 1-hour session at maximum is suggested.

Who?

• All stakeholders.
• Product owner.
• Scrum Master.
• Architect.
• Selected team members if their consultancy is necessary.

Outcomes of the sprint preplanning

• Scope for the next sprint agreed.
• The readiness of the requirement is indicated to the product owner so she can improve it if necessary before the next sprint planning.
• Rough estimation in story points.

Is sprint preplanning mandatory?

No. But highly suggested! Otherwise, teams expressed:

1. We are waiting for responses regarding the details for months!
2. There is no feedback, no answers. Just silence!
3. We started to work on requirements, however hardware or permissions to access systems is not provided. We can’t deliver the results which work.
4. Every stakeholder is trying to push the team to their own requirements. As they are unaligned, no stakeholder can get the results.
5. Stakeholders do not talk to each other. The product owner can’t decide about priorities as she is not aware of business impacts.
6. Technical debts are increasing. Business first leads to business never in a long-term perspective.
7. Frustration feeling. Blockage. No movement. Yet again. Feelings about the situation.
8. Unhappy customers. You will deliver just something, not what customers need.
9. Compromises are not from the company’s perspective, just what customers want and push.

How ScrumDesk supports sprint preplanning?