How do you balance innovation and maintenance in your sprint planning?

Involve your team members and stakeholders in the goal-setting and planning process. By including diverse perspectives and expertise, you can ensure that your goals and criteria are comprehensive, realistic, and aligned with everyone's expectations. Encourage open discussions, brainstorming, and negotiation to find the best solutions and priorities for your sprint.

One thing I've tripped over several times is seasonality in my timelines. When prioritizing deliverables, make sure you are involving the sales and distribution stakeholders to understand if there is seasonality to products. It doesn't help to finish a product or release at the end of its annual sales cycle, and you suffer twice because this instance also means that you didn't focus upon a different deliverables that could have been completed in time for its respective cycle.

I have found it useful to define a longer term vision of the product (over 3-5 years) and then define 2-3 SMART (Specific, Measurable, Achievable, Realistic and Timely) goals or objectives at a time. Each goal ideally results in a measurable outcome that can be tracked, reported and ultimately celebrated.

Strategic objectives are high-level goals that align with your product vision and overall business strategy. They outline the desired outcomes and benefits that you aim to achieve through your product development efforts. Aligning your sprint goals with these strategic objectives ensures that your work is purposeful and contributes directly to the long-term vision of your product.

Start by defining clear goals for the sprint, including both innovative projects and maintenance tasks. Prioritize the most important items and ensure that each has a clear objective and timeline.

Most teams I see drive ongoing development efforts: they _always_ have roadmap goals to hit, tech debt to pay down and user feedback to address. One solution could be to define swimlanes within your team's capacity and to find the right balance between them. For instance, you might decide that in Q2 the team needs to reserve 60% of their capacity to advance their roadmap and there may be a minimum of 20% capacity required for maintenance and tech debt work. This leaves 20% to address user feedback requests. Once the framework is established it's easier to review the proportion quarter on quarter and manage expectations around that. It's also easier to make a case for expanding the delivery capacity if the progress rate is insufficient.

When generating/validating ideas, it's important to consider various perspectives/data points. For example, you can analyze customer feedback & reviews to identify pain points. You can also analyze user behavior data to identify patterns that can inform your feature or improvement ideas. You can look at industry benchmarks and competitors to see how you stack up. It's important to consider perspectives and expertise of team members. Your team can provide valuable insights & ideas based on their own experience. Fostering a collaborative environment, you can generate more diverse ideas. Finally, it's important to keep in mind the broader context in which your product or service operates. For example, regulatory changes, economic trends etc.

Estimation is a double-edged sword, handle it with care. If done right it's immensely helpful in unblocking the team with quick decisions. If not, it turns into a tax on the team that limits them and creates arguments about prioritisation. In my experience, it takes two things to make task estimation helpful: - Work items need to be granular enough to fit 8-15 of them in one iteration - Estimates need to be consistent and reliable It pays to practice getting these things right before you can attempt to use estimates when committing to delivery goals.

We review new dev and tech debt with stakeholders to prioritize, estimate and get a single common score. (Sales, Product, Customer Support, Tech lead) Group common themes into sprints, and use estimates to build sprints into a roadmap. Review the progress, backlog and prioritize each quarter.

I've also seen best practices to follow the 20-60-20 rule for a portfolio approach: - 20% allocated to fixing tech debts - 60% allocated to building core features - 20% allocated to experimenting with innovative ideas (aka "venture bets")

I think that having solid prioritization of the backlog is vital. Negotiate with stakeholders and customers to assess how to best handle technical debt and maintenance within the product roadmap. Sometimes this requires having difficult conversations to reach an understanding. Remind them that continually not addressing the maintenance needs of the product will ultimately increase the cost and scope of that work in the future.

All really practical suggestions. Biggest challenge is to maintain focus on the goal once set and not being distracted by external challenges. The value of tech debt/ maintenance is underrated by those only focussing on commercial benefits. Yes, balancing a regular feed of tech debt is advisable but doesn’t always mean there is full transparency. Bring the tech debt value into focus and preach about the importance outside the squad.

Product innovation, like business innovation, requires a balanced approach that neither neglects nor dominates all efforts. Horizon thinking is a valuable framework for prioritising product initiatives, as it does in business. H1 focuses on core activities for product stability and maintenance, addressing vital operational aspects. H2 involves developments that improve the product and create value, using knowledge, experience, or insights. H3 signifies long-term or emerging bets that can drive substantial growth, transformation, or disruption. Using horizon thinking in product management, teams can efficiently allocate resources, maintain a stable product foundation, and explore innovative opportunities for well-rounded growth.

Agile methodologies like Scrum can help balance innovation and maintenance by breaking down work into smaller, more manageable tasks. This allows for more frequent releases and ensures that maintenance tasks are tackled regularly while still leaving room for innovative projects.