Ranking Backlog and Planning Sprints

At Zaleos, we are Agile practitioners and we've used both Scrum and Kanban as management methodologies. Today we actively use Scrum, but we're not an Agile purist shop: we use the methodology to suit our team's specific needs, allowing us to derive maximum benefits from it - and not the other way around.

At Zaleos, we do 1-3 weeks Sprints, usually, we schedule longer Sprints when we forecast national holidays, long weekends, or when several team members are going to take PTO. In a normal scenario, we use 1-week Sprints. We love the iterative approaches, measuring the team's output during the Sprint (velocity, carry-over rate, RCs shipped...), but also having retrospectives for the team to learn and act.

As part of our Agile ceremonies, we rank our backlog and plan upcoming sprints regularly as an ongoing daily process. We have a very good picture of how the next Sprint is going to look like (N+1), but also we have a good forecast of at least 2 Sprints more (N+2 and N+3). This everything-is-a-draft mentality helps us to maintain a flexible approach, avoiding rigid adherence until when is time to make a planning commitment and start the Sprint.

We have two main processes:

1- Backlog Ranking

In order to plan the Sprints, we must have a ranked backlog. We use the following prioritization criteria and each PBI (Product Backlog Item) is ranked using them:

• Business Value: Prioritize items that have a higher potential for generating revenue, cost savings, or competitive advantage.
• Business Impact: Prioritize PBIs that are critical business processes, or damage the reputation of the product or organization.
• Dev Effort: Prioritize PBIs that can be fixed with minimal effort, allowing the development team to address them quickly and efficiently as quick-winners.
• Technical Debt: Prioritize items that help reduce technical debt, improve code quality, or enhance system performance to ensure long-term maintainability and scalability.

Example of ranked backlog (using a weighted score)

2- Sprint Planning

In order to perform sprint planning and have a good picture of how the next Sprints are going to look, we start picking PBIs from the ranked backlog, but understanding other key factors:

• Team Capacity: Capacity and availability of the development team. Prioritize items that align with the team's expertise, skills, and available resources.
• Dependencies: Detect either technical dependencies (ex. a feature requires updating a library) or functional dependencies (ex. a feature requires another feature to be completed first).

Example of ranked backlog (PBI-4 depends on PBI-2 and velocity is 100 points)

Communication

Communication is very important. This ranked backlog and sprint planning must be accessible and transparent to any person that might be affected or interested (stakeholders, Zaleos' engineers, ...). Any uncertainty must be discussed and sorted out. Performing a final validation of the scope of the upcoming Sprint with businesses and technical leadership is also highly recommended.

Conclusion

Rank prioritization helps to deliver the most value to our business while also taking into account technical debt and development efforts. Our environment is too dynamic and constantly changing for us to stick to strict plans. Long-term planning just doesn't work for us, but having 3-sprint visibility does.

Maintaining a well-organized and up-to-date backlog, along with utilizing the shared ranking/prioritization and planning processes, helps us in forecasting and delivering great value in our software products.