Plan for the next sprint
With a refined and estimated backlog, the PM and the engineering lead can sit down and plan the work for the following sprint. The level of refinement should be such that as long as the backlog is prioritized, the team can pull stories without much debate or questions. The PM and engineering lead review previous sprints for median velocity and determine the amount of work that can be feature complete for the planned sprint. When planning, the team should consider the following:
- How many people are available to work on the entire sprint? Are there vacations, sick time, or any other time allocated outside shipping?
- What is the actual velocity of the team? If there’s a working history, what typically impacts the velocity (good or bad)?
- Do the selected stories fit within the sprint?
- Is the team expected to handle a certain amount of change within the sprint? Should throughput be mapped to, for example, production support throughout?
- Are there any production-related items to escalate into the sprint? For example, is UAT testing returning critical defects?
- Under what conditions can a story roll over from one sprint to another?
- Can incomplete stories ship?
- How is feedback from the demo handled in the context of the planned backlog?
- What if the client requests a high-priority change for the next sprint during a demo?
- How does the team track and address critical bugs within the available bandwidth?
In an ideal world, any team member is equipped to handle any story in the backlog. However, the reality and nuanced nature of building custom software often requires the engineering lead to route appropriate stories to individuals according to their specific areas of expertise—for example, data model design for performance may require specialized knowledge, front end versus back end.
Teams should always aim to improve velocity and do more with less. Even if we don’t spend the full allocated budget, our excellent performance will lead to follow-up work.
A high-functioning team may not even need a product manager in the planning session. With trust established, the product manager is able to push ahead while the rest of the team plans their own sprint and ships working software.
