Embrace Change with Continuous Planning and Refinement

A daily rhythm can help.

Adapting all time horizons each Sprint helps you ensure a holistic response to learning insights.

The opposite approach, big planning up front, doesn’t enable an Agile response to change.

But it does provide a sense of comfort. I remember an executive once said to me, “Detail provides comfort.” This is true. Detail creates a sense of being in control—that you have covered all the bases. Unfortunately, this control is an illusion in the complex, uncertain product development world.

Plus, all those upfront plans stifle a quick response. The tendency is to stick to the plan rather than respond to changes on the fly.

There are many forms of big planning up front, such as:

• Program Increment (PI) planning
• Feature and date-driven Product Roadmap planning
• Upfront release planning
• Quarterly planning
• Monthly planning
• Sprint planning
• Yearly budgeting
• Dependency mapping
• Detailed, upfront architecture design
• Research and design phases
• Lengthy, upfront cost-benefit analysis

Each of these planning activities creates a plan that begins to stale soon after creation. As new information emerges, the plan often remains unchanged. Getting all players back together is often too difficult due to competing priorities. The burden to replan is too great.

The more unfortunate reality happens when we treat these plans like a contract. We do everything possible to stick to the plan. And in doing so, we lose our ability to adapt to change.

So the effort and time to create the big, upfront plan are often wasted. And it ends up creating more waste as we struggle to adhere to it.

What is the alternative? Is there anything better?

Smaller, frequent planning is a better alternative. It adds simplicity and improves responsiveness to change. How frequent? Planning and refining your Product Backlog daily should be the goal. Yes, that’s right…daily.

Daily planning and refinement keep the detail low and effort to plan and refine small. And it creates a habitual cadence for responding to change. Daily refinement is best used to consider all time horizons.

Responding to change over following a plan,

—The Fourth Value of the Agile Manifesto

You may be asking how this is possible. Believe me, I was skeptical at first, too. But it works. It simplifies planning, and it builds team muscle for responding to change.

Let’s describe the three horizons and a continuous, daily adaptation framework for them.

---

The Three Planning Horizons

There are three planning and refinement time horizons—Now, Next, and Later. Sometimes I have referred to these as today, tomorrow, and the day after tomorrow. Reflecting uncertainty, detail reduces as the time horizon extends further into the future.

The trick is to achieve continuous inspection and adaptation of each horizon. A daily cadence provides a construct for frequent consideration of all three horizons. Through this discipline, you will be able to embrace change as it occurs.

Now

The Now time horizon is your current Sprint. You form a Sprint Goal and Sprint Backlog during Sprint Planning. The Sprint Backlog contains selected Product Backlog items and a plan to deliver them to meet the Sprint Goal.

But the Sprint Backlog is not meant to stay frozen in time after Sprint Planning. As learning happens, the team adjusts the Sprint Backlog to ensure they meet the Sprint Goal. This includes adjustment of both the Product Backlog items and the plan to deliver them.

Modification of the Sprint Backlog happens during the Daily Scrum. So the team adjusts to the reality on the ground every day.

Given this, your team can benefit from resisting the urge to over-plan at the beginning of the Sprint. They should plan enough to devise a reasonable game plan but also have a bias for beginning the work. Getting started turns on the learning. And learning will help guide your team‘s path to their Sprint Goal better than the plan.

Next

When we assess our Next time horizon, we are assessing our Sprint Goal for the next Sprint. And we build a shared understanding of the Product Backlog items to meet the next Sprint Goal. This is often referred to as getting Product Backlog items “Ready” for the next Sprint. In Scrum, this an aspect of Backlog Refinement.

We incorporate learning insights into planning for what’s Next. This learning comes from several sources, such as:

• New ideas from the Scrum Team
• Last Sprint’s Sprint Review feedback
• Learning experiments
• Changing business contexts
• Emerging customer needs
• Better understanding of your technology context
  

When we look into what’s next, we are less detailed than in the Sprint Backlog crafted for the Now time horizon. Refinement for next Sprint focuses more on user needs and goals. We defer detailed planning on how we will do the work until what is Next becomes the Now.

Later

Everything after the next Sprint is the Later time horizon. This is the second aspect of Backlog Refinement. And it includes refinement of the current Release and Product Roadmap goals.

The current Release Plan and the Product Roadmap are goal-oriented. They target customer and business outcomes.

We avoid setting a date and listing features on the Release Plan. Any forecasted dates show as a range based on our level of uncertainty. If we list major feature options on the Release Plan, they are options and nothing more.

While hard to resist the temptation, it is best for a Product Roadmap to have no dates and no feature options shown. This reflects our uncertainty on how we will solve the target goals.

Later planning aims to address a customer need and achieve a business impact. We target key results and outline how we will measure the achievement of these results. As we deliver and learn, we adjust these needs and goals to the reality on the ground.

The Backlog Refinement Hierarchy of Needs

It is up to the Scrum team to assess how often backlog refinement happens. Some teams choose to do one or two refinement sessions per Sprint.

Often these meetings end up being too long and there is too much to cover. The Scrum Guide suggests you spend no more than 10% of your Sprint capacity on Backlog Refinement. This is about four hours per Sprint week. A four-hour meeting for a one week Sprint is not my idea of fun.

And less frequent refinement sessions will not provide a chance for having many conversations. It often takes several conversations to converge on a shared understanding. Having a break between sessions allows your team to marinate on ideas. I find this break crucial for stimulating the creative process. It invites fresh perspectives.

So the better solution to try carves out time each day during the Sprint to do a little Backlog Refinement. This keeps the refinement batch small. And it provides ample opportunity to refine understanding and incorporate new insights.

Daily refinement allows you to progress through all future time horizons each Sprint. The daily sessions flow through a hierarchy of Backlog Refinement needs as discussed in the next video.

This hierarchy of refinement needs ensures we focus on learning first. We follow learning with refining the Release. Then, we prepare for the next Sprint. Finally, we address the Product Roadmap. Daily refinement allows you to reflect and pivot on all future time horizons each Sprint.

---

Taking It Forward

If we are developing a product, we must embrace change. Big planning up front creates a false sense of security. And a detailed plan holds us hostage. We can easily find ourselves following a stale plan versus responding to reality.

If we have a daily habit of continual refinement of our future plans, we keep our plans fresh. And we adjust our path one small bite at a time. Planning detail reduces as time horizons increase further into the future. This is a true reflection of the real uncertainty that we face.

It is possible to continually plan and refine our product course every day. Try continuous refinement and planning today. Embrace learning. Embrace change.

Also published in Serious Scrum on Medium.

---

Related Posts

Check out similar posts to this one below:

Less Is More When You Scale Agile

Mistake-proofing Your Product Development with Scrum

Is Finishing What You Start The Best Choice?

Surviving Agile Without a Status Report—Engaging With the Team