Zuzi Sochova - Agile and Scrum Blog

Kanban is not Scrum, Scrum is Kanban

I often get question what is Kanban and if it is better than Scrum. So let us start with explanation of what Kanban is. It’s a very light method coming from ancient Japan and then popularized by Toyota. It has three rules:

Limit work in progress (WIP)
Visualize
Minimize lead time

That’s all. You can start with any process, visualize it and based on what you see improve the throughput and bottlenecks. It’s simple, it works. But you have to be really improving based on what you see. Companies are often going to Kanban because the change required by real Scrum is too painful. So they do some board (you can’t usually see much from it), and say we are done.

Because Kanban doesn’t really help you with implementation and mindset change, Scrum is so successful comparing to Kanban (I’m not saying that Scrum is simple, but the opposite). So if you truly think about the three above principles, you find out that Scrum actually embraces Kanban at many levels. So let’s go one by one.

Limit work in progress (WIP)

In Scrum we have Sprint backlog to fix number of backlog items / User Stories in Sprint.

It’s a common practice to say that each person can work at one task at a time. Once it’s done they can take another one. Two (and more) people can work on one task to make it done faster.

Successful teams work one UserStory at a time. As a team, they take one Backlog Item and finish it. Once it’s done, they take another one and collaborate on it.

Visualize

Sprint backlog is visible, defined, well understood.

Common practice is to have Scrum board to visualize sprint progress and help team members collaborate.

We make our backlog and priorities visible to everyone.

Sprint review shows the done functionality every Sprint.

Minimize Lead time

Sprint Backlog and Definition of Done is here to make sure teams finish working software each Sprint.

Scrum says the shorter Sprint, the better. So most of the teams now have two weeks Sprints and there is strong trend to one week Sprint.

Common Kanban/Scrum misunderstanding

One of the most common misunderstandings and reasons why people choose Kanban and leaving Scrum is that we can’t deliver working software any time during the Sprint in Scrum. We have to wait to the end of Sprint they say. But there is nothing in Scrum which would prevent you from continuous delivery. The only changes you need to do regarding team practices (note it has nothing to do with Scrum itself) is to adjust your definition of done (DoD) by adding “running on production server” and let team to work ‘one Story at a time’ so they deliver done functional stories one by one. Any time during the Sprint they are done with that story (done means it’s according to the DoD) the functionality is already at the production. Simple and straightforward 🙂 right?

So all around, there is no reason to leave Scrum. By the way, if it’s not fun to be Scrum, it’s most likely not Scrum, so inspect and adapt the way you work. If you are looking for some useful tools how to make it working and how to make it more fun, you can check my new book The Great ScrumMaster.

How to make your Retrospective great?

Retrospective is the crucial part of your success. Through Retrospective you implement Inspect and Adapt principles. Through Retrospective you learn and become better team, product group, and organization. So let’s have a look at a few tips about how ScrumMasters (but not only ScrumMasters) can make Retrospective great.

Understand the goal

The typical mistake in the beginning is that teams and ScrumMasters use the Retrospective only to discuss issues or complaints. The goal of the Retrospective is not to say what went well and what went wrong, but to improve. And in order to improve, you need to get clear list of action items actionable next Sprint as a result of every Retrospective. The frustration of some teams is coming from the fact that they can’t solve everything right away. ScrumMasters shall help them to find the first step and make sure they are able to make it. Then celebrate the success and find a next improvement. Don’t take too many action items. One, two or three are more than enough. Quantity is not the quality here.

Find root cause, don’t solve symptoms

Another tool which can help you to make your Retrospective great is root cause analysis. Too many times you spent time and energy in solving symptoms. The particular issue would got solved, but soon another two emerged. It’s never ending. Instead, whenever team identifies any problem, ask them to investigate it a little, why is it happening, when, who gets involved, what is the impact of it, what can cause it, etc. Once you understand it, in most of the cases you realize that the root cause is somewhere else then in the identified problematic situation. And more than that, once we address it, it solves many other issues we’ve been facing and didn’t know what to do with them.

root cause

Change the format of the Retrospective

Sometimes, even if you facilitate it right, teams are saying that they don’t get enough value from the Retrospective anymore. It used to be great but now we somehow lost the focus and it’s not that useful anymore. People are not coming with new ideas; it’s hard to identify any improvements. It usually happens when ScrumMaster uses the same format of the Retrospective all the time – i.e. “plus/delta”, or star with “Start, More, Less, Stop and Continue”. It became a routine. So here is the hint how to make your Retrospective again engaging. Every time you facilitate Retrospective, make it different. Use a different format, ask different questions. My favorite question is “What made you smile last Sprint? / What do you want to change?” You would be surprised like such a small difference change the energy of the meeting, brings different attitude and helps you make the whole retrospective in more creative environment. Once people get used to it, involve the whole team in designing the retrospective format.

If you find it interesting and want to know more, you can watch my conference talk on Agile Retrospective below or get my new book The Great ScrumMaster.

Organization 3.0 – How to Achieve Modern Agile Organization

Organization 1.0

Organizations are constantly evolving. In the 1970’s the most common organizational structure was the pyramid structure. It was deep, hierarchical, and full of power. Companies got strong bosses who lead such structure. Internally their approach was full of command and control, bureaucracy, and standardization.

organization 1.0 Those pyramid hierarchical structures were not wrong in any way. They were the perfect solution to world industrialization and to the dynamics of business at that time. Most of the companies followed the best practices for a simple world, where problems can be classified as obvious, and applied a simple structure to address it. And it worked. Bosses got results. Companies started growing and became more successful.

The most common management tool was a carrot and a stick, because organizations believed that their employees are lazy slackers who can’t work without it. Most of the people were in a mood of tribal leadership 2 where the motto is “my life sucks”. Complaining all the time. Not happy, not motivated. Their only motivation to do something was driven by getting some bonus – a carrot, or because they were forced to – a stick.

Organization 2.0

Twenty years later, Organization 2.0 was here addressing the difficulty of the business world focusing on specialization, processes, and structure. Companies realized that the world is not simple any more, and the majority of problems can be classified as complicated.
As a result, they adopted complicated processes, focused on deep analysis, and invested in experts.

The belief in Organization 2.0 is that complicated problems need experienced individuals and detailed analysis. As a result, companies invested in learning and specialization. They began to grow. The work which used to be done by one person, now needed specific and dedicated positions. We’ve got a specialized department to deal with java, database, testing, architecture, analysis, documentation, customers, accounts, plans, and chair purchases.

organization 2.0 Organizations are trying to create a process to describe everything, to have every possibility thought over. Companies create career paths and talk about motivation. They have spent months describing KPIs, but the more processes and specializations they had, the less responsibility and goal driven individuals they had. They were starving. They tried to cut on expenses, but that did not bring any long term success either.

So they dream about the previous stage, where it was much easier to manage resources. At that time, managers had real power. They could make decisions. They could force people to work. They could use the carrot and the stick. It was so simple – no need for committees, no need to call a meeting for every single detail. At that time, allocation of individual resources did not cost most of their time.

Leader-follower leadership style The pressure on individuals to make themselves more successful, better, and smarter than others was huge. “What if my colleague is be better in the performance review?” “What if I am not promoted in two years?” It leads to a culture that emphasizes own goals over the organizational ones. Most of the managers and experts live in the third level of the tribal leadership model, where they believe that “I’m great, but you are not.” So they treat their employees and colleagues with little respect or trust. This leads to the leadership style of “leader-follower”, where the managers decide, and the people below them just do the job. No initiative is expected. People just follow the process and do what is ordered.

Organization 3.0

Nowadays, when the world is not complicated anymore, neither Organization 1.0 nor Organization 2.0 can address its full complexity. We have realized that such complexity needs a very different approach that can keep up with business dynamics. The Agile environment brings Organization, 3.0 which builds on teams instead of individuals, on different styles of leadership, and on intensive collaboration through the dynamic network structure. We need to completely change the leadership style, create partnerships, enforce self-organization, enforce real responsibility and ownership, enforce trust and transparency, and build the organization as a network structure which is flexible enough so that it can effectively respond to change. Decentralization is taking over, and is bringing a certain level of autonomy to self-organized systems.

Agile Organization - organization 3.0

Instead of being a huge tanker, you can imagine the Organization 3.0 as a flotilla of smaller boats, going into the same direction, living in the same context, having the same values, but making some decisions differently based on the situation.

The Organization 3.0 is a true Agile organization. In order to build it, you need to apply a different leadership style of “leader-leader”, which supports growth of people, instead of “leader-follower” which is so common in Organization 1.0 and Organization 2.0. Hand in hand with this new leadership style, you need to create a culture of tribal leadership “We are great!” where the focus is not on the individuals but on the systems and teams.

Leader-leader leadership style

Organizations are complex, as they have to deal with people’s behavior. People are not predictable. Every time we tried to make them behave in a predictable way, we failed. A modern Agile organization is built from people. It is a collaborative, creative, and adaptive network. It’s a sphere built from autonomous systems which are connected to each other, so they influence themselves but still keep consistent. Such a change of mindset is a huge mental challenge for most organizations.

So how to start?

– Help all people to become better leaders by applying the “leader-leader” leadership style, and build a culture of tribal leadership: “We are great!”
– Decentralize, build networks and communities.
– Allow autonomy in a well-defined context.
– Read my book The Great ScrumMaster, which is a guidebook not only for ScrumMasters, but also for leaders of any organization who want to become an Organization 3.0.

You can see my talk Agile Organization – Organization 3.0 at AGILEEE Conference 2016:

#ScrumMasterWay concept

During my CSM – Certified ScrumMaster classes and Agile coaching assignments I realized that the most difficult part of a ScrumMaster role is to accept your goal, and to create a self-organized team. Through the application of the ScrumMaster State of Mind model, you can help teams to become awesome. Once we have gone through all of that, there is almost always one question raised up. What shall ScrumMaster do if we achieved it and the team becomes self-organized?

Then it’s good to understand the #ScrumMasterWay concept, which divides work of ScrumMaster into three levels.

#ScrumMasterWay: My team

In this level – My team – it is all about my development team. How to make them understand the Agile mindset and Scrum values? How shall we shall become a good team? How will they embrace Agile practices? How can we collaborate, learn, and change the way we work? In the beginning, this may be a lot of work, but after some time you will have little to do here and you will stay more and more in the observing circle of the ScrumMaster State of Mind model.

#ScrumMasterWay: Relationships

The next level is creating a broader context of the ScrumMaster role. At this level, a ScrumMaster is looking at the team from a longer distance, making sure all relationships with other teams, Product Owner, customers, and managers are working fine. Have in mind that the ultimate goal of a ScrumMaster is still the same, to improve self-organization. At this time ScrumMasters often attend CSPO, MNG30, team coaching.

#ScrumMasterWay: Entire System

The last stage focuses on the entire system. ScrumMaster is looking at the overall organization from a distance, searching for culture changes, environment improvements and behavior patterns. This stage is focused on application of Agile and Scrum philosophy. Without this level you will never create modern Agile Organization.

If you find it interesting, you can read more at my last book – The Great ScrumMaster – #ScrumMaster Way

The Great ScrumMaster

Great ScrumMasters are rare. Not because it is too difficult to become a great ScrumMaster, but because there is not enough advises on how to become one. Here are a few tips on how to become a great ScrumMaster. If you find this interesting, I’ve just finished a book, The Great ScrumMaster on Amazon.

Leadership

Great ScrumMasters are leaders. They know how to create leaders from others. They believe in others and help them to become successful. They can create active communities and heal relationships. Don’t make them team assistants. They are coaches and facilitators.

Curiosity

The attitude you should bring along is curiosity and respect. Be a cultural anthropologist. Your role has never been to tell others what to do, but to understand them. Be able to see them as people. Don’t be judgmental. Being a ScrumMaster is like playing a strategic game. Be creative in searching different ways to approach teams and organizations.

Learning

Being a ScrumMaster, you are never done with learning. Attend Agile conferences, watch videos, read books and blogs. But there is more than that. Most ScrumMasters are missing any experiences in coaching, facilitation and change management. You can start with a book, but you need to experience it and practice it. So find one class per year to attend, and continuously improve your skills in the mentioned areas.

Self-organization

The goal of ScrumMaster is to build self-organized teams around them. Keep it in mind when you are working with a team. ScrumMaster is not any team assistant, nor their mother to do the work instead of them and prevent them from failing. In order to learn, teams must fail sometimes. They must grow up and become self-confident, take over responsibility and ownership.

System

Work at all three levels of the #ScrumMasterWay concept. Especially the last one – ‘Entire System’ is critical to your successful great ScrumMaster journey. In order to succeed here, you need to understand the system thinking and be able to approach the entire organization as a system. A systems view makes your role more interesting and fun.

The book

The book contains many practical examples, tips, and exercises. It’s a guidebook on how to become a great ScrumMaster. You can get the book at Amazon. I hope you will enjoy it.

ScrumMaster State of Mind Model

The state of Agile and Scrum understanding in organizations is not, in any way, great. Many Scrum implementations are failing not because Scrum doesn’t work for the particular organization, but because companies lack the core understanding of the Agile and Scrum mindset. During the Certified Scrum Classes (CSM) I have taught across the world, I realized that even ScrumMasters who were supposed to be Scrum experts are often struggling with understanding the consequences. That was the key motivation for writing a book dedicated to all ScrumMasters and leaders of Agile transformation in organizations: The Great ScrumMaster – #ScrumMasterWay, which is published on Amazon.

ScrumMaster State of Mind model

One of the concepts described in the book is the ScrumMaster State of Mind. It shows ScrumMasters how their day should look like. What are the approaches, they should use in different situations. The ScrumMaster State of Mind model defines four quadrants, with four different approaches you can decide to apply. They are all equally important and each of them can be used in all team development stages.

Teaching, Mentoring, Sharing Experiences

This approach builds on top of your knowledge and experience. Especially at the beginning of your Scrum adoption journey, you have to be clear on the purpose of the individual practices. Teach individuals, teams, and organization about the mindset. In later stages, you shall share your experiences, teach new practices, and help people to improve.

Removing impediments

The second approach you can take is removing impediments. It’s critical to take off the team’s frustration, but this is not the goal of great a ScrumMaster. A great ScrumMaster is not any team assistant, so don’t take this approach too often.

Facilitation

Facilitation is more than just leading Scrum meetings. As a facilitator, a ScrumMaster should know how to make conversations efficient and smooth. A ScrumMaster should know how to help people and team to agree and make a decision. The ability to facilitate is critical for team success.

Coaching

As the last approach, there is coaching. The fundamental difference between coaching and mentoring is that as a coach, you don’t share your own experiences, but ask questions so the team will realize where they want to go. They are the experts, not a ScrumMaster. This approach is critical to your long-term success, as without good coaching, you can never create great teams.

Observing

Even though the mentioned approaches are important, there is one in addition in the middle. This middle circle is about observing and making intentional decision on where to go. It should always be your base position. The place where you start, and return back again when you apply one of the approaches, to see how it landed with a team. It helps you to react on different situations differently. Even when you make a wrong decision, and for example, teach a team who believes they know everything better already, using the State of Mind concept helps you make corrections early enough.

Global Scrum Gathering® Prague 2015

I’ve got a unique opportunity to be co-chair of the global Scrum Gathering Prague. It’s an event for all Agile and Scrum enthusiasts around the globe – the European Gathering usually got around 600 people.

The theme was structured around the five senses to challenge agile mindset and support the Scrum Alliance’s goal of “Transforming the World of Work”. The unofficial theme was how to address complexity and how companies need to change in order to address such change and sustain the market expectations.

I especially enjoyed the opening keynote from Niels Pflaeging (if you are looking for a keynote, he is definitely part of my top#10 suggestions). He’s been talking about change in the management over past few decades. He explained that Taylorism is dead. That traditional management is not applicable for current extremely dynamic and global world. The world, which is not complicated, as it used to be, but it is complex and brings us surprises every day. You can’t respond by new process or standardization. It changes so fast so it’s not possible anymore. To answer complexity you have to use new tools like System Thinking or Organization and Relationship Systems Coaching.

Another surprise was lightning talks. They’ve been selected by audience using dot voting (very agile way, huh?) during the first day and they’ve been all great. Add finally I very much enjoyed Pecha Kucha format. If you never seen it it’s 20 slides auto forwarding after 20 seconds. Very nice format. Enjoyable. It forces speakers to speak to the subject and keep rhythm. And/but you have to be great speaker to make it.

The last day we’ve got an openspace. It’s always full of people, and engaging, but this time I was very much amazed by how many people attended Stuart’s illustration session. He’s been running a workshop on drawing and visual facilitation techniques and he’s got more than 150 people at this openspace session. If you missed it, don’t worry we are going to invite Stuart to Agile Prague Conference 12-13Sep 2016 so you have second chance :).

Organization and Relationship Systems Coaching – ORSC and Agile

Recently I passed extensive training on ORSC – Organization and Relationship Systems Coaching. Not sure if you know ORSC, so let me introduce it first. ORSC is a coaching model where we focus not on the individuals but systems and the relationships in it. System – for your understanding – could be anything like pair, group of people, team, department or organization. The latter mentioned are exactly what makes me interested and curious. Coaching teams is something each Scrum Master is doing so let’s get some different framework which can help here. Coaching organizations as an entity could move Agile transformation to the next level and give Agile Coaches another tools how to make it happen. So I was in.

The whole program was divided into five classes – Fundamentals, Intelligence, Geography, Path, and System Integration. I passed the first ORSC class in London and the rest in Toronto. It’s always great to combine work and holiday and Canada was just awesome 🙂 In between of classes I’ve got some time to try individual concepts at my clients and got used to the new models, terminology and approaches.

I’m going to share a couple of my favorite concepts which I found easy applicable in Agile environment.

#1 DTA – Design team alliance

I apparently knew this concept for a few years as it has been introduced at Agile Coaching Institute class: ‘Moving to the Next Level’, which was created together with ORSC leaders. However, it took me some time before I fully understood the importance of such agreement. What is it about? Seems to be simple – let team agree how they would like to be together, what makes them great team, and what are they going to do if things go difficult. Actually it’s quite similar to the retrospective with exception of the fact that you do it up front. You might link it to the futurespective, as that is a kind of similar as it looks forward, but it’s still something else. With DTA we focus on relationships and not so much on the particular potential problems and solutions. You need to coach the team to stay out of those concrete solutions. Because even if they brainstorm a lot, they never come up with every possible future issue. So we are looking to the system from the top, trying to straighten its connections to survive any potential difficulties. Don’t forget we are not solving or preventing potential issues, but agreeing on the way how we are going to solve such situations in the future.

#2 Everyone is right but only partially

When you start to look at the group of people as a system, which you can imagine as looking down on the team from few kilometers / 10 thousand feet high distance, the particular issues and problems are not so important from that point of view. You are focusing on the linkage among the people instead of individual persons or their problems. From such viewpoint this System Rule – Everyone is right but only partially – is extremely helpful. It helps you to coach system and don’t let yourself to take sides. Moreover, every system is intelligent by itself. It will tell you if there is something wrong. And your entire job as System Coach is to listen for those signals and reveal them back to the system so that the system can react and possibly solve the issue or improve itself. You are not here to solve it for them, you shall only help them to straighten their relationship, and let the relationship to fix it.

#3 Importance of Appreciation and Positivity

We, Europeans, are never using so much of an appreciation as our US colleagues. And it’s been a challenge for me and also for one German girl during the class. However, despite on how silly it feels, it works. So I’m going to appreciate more. Even if it is painful.

The second concept which is actually quite connected to the appreciation is positivity. Especially for always complaining Czech society it’s extremely useful :). Did you know that good teams have its positivity: negativity ration at least 5:1? And how is it for your team? Positivity will not just happen, you must garden it, search for it, help it to become an integral part of your system.

#4 Toxins or so called Horsemen

There are four toxin behaviors which team should avoid. Defensiveness, Blame, Stonewalling, Contempt. Everyone does bit of it from time to time, however just educate on them would limit their dominance. So my learning point here is to educate teams on toxins, and coach them to understand the impact of them to the team health. I believe the awareness by itself will help team to be better.

#5 Three Levels of Reality

Finally, there is a concept which made my day. At the beginning, it had been completely incomprehensible. I was lost. Our trainers mentioned we may only get it at the end of the module. But I was completely desperate. What the hell it means? But sometime during the last day of the module it got to me all at once. And I realized that understanding this concept is a key factor for thousands of situations I’ve been trying to improve in my Agile Coach work.

And here is my challenge with it. It took me full three days to get it, so how am I going to arrange such experience to my clients in much shorter time? I guess using the ORSC coaching framework. But still, it’s a challenge.

What is it about? That there are three levels of reality. Sentient Essence Level, Dreaming Level, and Consensus Reality Level. And you often need all three to succeed. And me as a System Coach can help to navigate individuals, teams and organization through essence to start dreaming and through that understand or change their consensus reality. It’s very powerful. And if you feel like ‘too fluffy’ or ‘what the hell is interesting there?’ just note I’ve been struggling a lot with it at the first time as well.

Recommendation

Finally, would I recommend you passing ORSC training? It cost quite some money so it’s better to ask, right? I would say it’s been one of my best decisions. However, I believe you need some Coaching education and experiences before you go on and sign up. For that background I would recommend you start with Agile Coaching Teams and Agile Facilitation class – both classes are from Agile Coaching Institute. And then go on with ORSC – which I would recommend to all Scrum Masters who want to move their role to the next level and focus more on the organization and systems then individual Agile practices. And to all Agile Coaches, because without it you are not true Agile Coach.

Agile Prague Conference 2015

Agile Prague Conference 2015 – Sep 14-15, 2015 got awesome speakers for this year. We were able to get unique experts from all different areas of Agile and Scrum. We have talks on Agile Product Management, Scaling Scrum, DevOps, Test Driven Development – TDD, Behavior Driven Development – BDD, change and improvements.

This year we continue with 2 full conference days – every day we plan for 2 parallel tracks and one additional workshop/game/open space track in the afternoons at open area.

So far you can be looking forward to the following keynote speakers:

– Jurgen Appelo | selected by Inc. “100 Great Leadership Speakers for Your Next Conference”

– David Hussman | author of the Dude’s Law

– Joshua Kerievsky | protect people by engineering anzen (“safety” in Japanese) into workspaces and code bases

– Bas Vodde | creator of Large-Scale Scrum (LeSS), a framework for scaling agile development

and talks from:

– Vasco Duarte | improving estimates for software with #NoEstimates

– Andrea Provaglio | speaking at AgilePrague for the 5th time

– Jutta Eckstein | enabling Agile development on the organizational level

– Senta Jakobsen | enables distributed development

– Cliff Hazell | at Spotify we aim to build shared views and models to reduce unnecessary ambiguity

– Oded Tamir | DevOps is taking the Agile to the next level

– Pawel Brodzinski | the missing bit is almost never a tool or a method but sort of myth
and that’s indeed not all.

Those wonderful speakers are just beginning of our list. In addition you can be looking forward to games, workshops, case-studies, and last but not least an Open Jam session – believe it or not, for most of conference attendees the open space is the most valuable part of every conference. How it works? Bring your idea/question/theme to discuss and run a session yourselves. Or join any group where you are interested in the subject and share your experiences and hints. Or just listen. It’s an awesome opportunity to get insights from each other.

Looking forward? Have a look to Agile Prague Conference web site, full program and register now!

Sprint Planning in 30 minutes

How much time takes your team to finish Sprint Planning? To my experience it could be anything in between of above mentioned 30 minutes and full day. If you are closer to the second option and it feels scary, annoying, waste of time for you, let’s have a look at few recommendations how to cut it out into 30 minutes.

First, let’s see how to run the Sprint Planning itself. I recommend Product Owners to come to the Sprint Planning with physical cards for each User Story. They quickly introduce them, answer questions if needed and then let the team choose out of them. Don’t bring the exact ordered list; let them freely choose from the cards. There are two reasons for that. First, you maximize work done as they can organize themselves in a way they are most efficient, and at the same time there is higher commitment as well. Second, you build a trust between team and Product Owner. You trust them they will choose the right User Story which brings the highest value at the moment. Once the team select the User Stories witch they believe they are able to finish within the next Sprint and put them on Scrum board, Product Owner and Scrum Master can leave and let the team finish the Sprint Planning. During this second phase team will collaboratively split the selected User Stories into maximum one day tasks and revise the Sprint Backlog commitment. After 30 min they are done, have full board of cards and can start working.

If that still feel unbelievable, let’s have a look to the preparation. There are three key recommendations you should do in order to make your planning fast and meaningful. First is for Product Owner. 2-3 days before the Sprint planning let the team know what are your priorities for the next Sprint, so they can have a look and prepare themselves, ask questions, etc. Second is proper Backlog Grooming. The goal of Backlog Grooming is make sure the team understand Product/Release backlog (i.e. all User Stories, Super User Stories, Epics and vision). At this time team do the estimations and help Product Owner to split User Stories which are too big, or add Acceptance Criteria. Once understood, they are ready to be planned to the Sprint.

To summarize it, if you are not able to do such fast planning, improve your preparation (team time to prepare, grooming, pre-planning) so the planning is here not to investigate new functionality but to confirm how much we can make. Doing that, you gain motivated team who is not wasting time at never ending planning, better reliable Sprint plans and higher backlog quality as you are not pushed to do splits and changes at the last moment. Start step by step and continuously decrease your time needed. It’ll go much faster than you would imagine.