If you work in Sprints, when do you look at project deadlines?
I received an excellent question recently and wanted to publish the question and my answer.
If a project has deadlines for features that will be ready by a specific date and the team works in agile, plans 2 week long sprints of work, sprint plan, etc. How/When do the team look at the deadline date and features, to see that things are getting done in the right pace? Related to that — should a team also have plan out future sprints and not only current sprint?
There are two ways to prioritize value. ROI-ordered Backlog to “deliver the highest overall lifetime value” or High Value First to deliver the highest value within a shorter, fixed window. You are likely to have demand for the latter in agency work or against quarterly objectives.
Other patterns to consider: Release Range gives estimates for what is possible in the future given best and worst case sprint velocity. You can work backwards from your ultimate deadline to determine what to sacrifice to make it a reality.
Sprint planning itself should occur fresh each sprint. But product backlog ordering and estimation can and should happen well into the future. Just keep in mind that the further out it is planned the higher risk the later parts of the plan are of being undermined by changing demands from new insights or market forces.
One thing about utilizing Agility is it implies you have to first admit the reality of changing scope revealed as the team gets closer to the deadline. You can’t have an immutable fixed scope with fixed deadline. When has the client ever not realized late a critical aspect they needed? When has a team ever not learned something before the deadline that impacts the original assumptions?
But you are right to beware blind progress sprint to sprint. PO needs to keep the backlog ordered and estimated in a way which is divided by optimistic and pessimistic velocity to demonstrate the range in which that list can be accomplished.
The PO better have the backlog estimated and ordered in a way that will serve that deadline. The engineers will reveal the reality of their rolling average velocity over each sprint. That engineering capacity can be considered fixed at the average rolling velocity at the time of each new planning. The engineering capacity of a team’s given sprint can be influenced over time with change in process and competence. PO has zero control over it and should liken it to a printer with a fixed printing rate. It is therefore critical to queue the correct and accurate requests for the engineering capacity to deliver at a sustainable pace.
The time to look at the long term goal is every sprint review with the entire Scrum team and key stakeholders. That is where the whole team including stakeholders takes stock of progress and direction. The sprint review is tragically underutilized in my experience but it’s THE event for ALL to understand progress and re-assess goal viability and to adapt the product backlog to meet the reality revealed in each sprint review