The Power of Metaphors

One of the tools I have started using more over the years is a metaphor. Many years ago I was taught the Speed Boat retrospective and tried it with teams. It brought great energy and fun, it helped us to uncover different perspectives. But it never occurred to me that I should take the idea to the next level and use it in other situations. So let’s have a look at different situations where metaphor can be useful.

Organizations are often used to look at outputs, measure effort, and compare velocity. One of the shifts that need to happen is from functionality to business value or in other words from output to outcome. And it’s not an easy shift, especially when the organization is still project-oriented, running on the “fixed scope” mindset. One of the reasons I’m using the metaphor with Product Owners is to shake with their business as usual – we deliver requirements – and reset their thinking about the product. I’m leveraging the Three levels of Reality concept I learned from ORSC and guiding them through the Sentient Essence level by exploring a metaphor, through the Dreaming level where the most collaboration at Backlog refinement is happening, to the Consensus Reality level they are used to by setting goals and objectives. The Sentient Essence level is about feelings it’s the spirit of things. It’s where the purpose is born. And the purpose is often forgotten in traditional organizations.

Three Levels of Reality

Using a metaphor is also a great icebreaker and team building. You see how different people collaborate, how they react to different perspectives, and look for commonalities. It can help teams to create an identity and become a better team together.

It’s also a great tool for ScrumMasters to reflect on where they like to have the team or the entire organization in six months, a year, or three years.

I’m often starting by letting individuals draw some animal, real or imaginary. Depending on the situation I might help them explore that metaphor more to uncover different aspects of it. Drawing is just one way how to visualize the metaphor. You can ask people to describe it, to create a gesture, song, or dance. There are no limits.

For example “We are like a flock of birds, they can fly fast, but not for long. Some got tired quickly and started falling down but the others continued without noticing. They are strong, they have great eyes, but once they start the journey they don’t like to change the direction.”

Then we compare the individual drawings, looking for similarities and uncovering the differences. And start integrating different perspectives into a coherent picture. It’s different than talking about numbers, goals, and objectives. It brings energy and creativity and I would encourage you to try it. Let me know how it worked for you.

Failing Fast

To my huge surprise, I realized that the concept of failing fast and learning from failure is difficult for some people to accept. They always feel the frustration when I say that ScrumMaster needs to feel comfortable to let the team fail so they can learn. I wrote about it here a few times, so you most likely know it, but the goal of a ScrumMaster is to make teams self-organized. They are not their assistant nor their mothers (as it might end by being dependent on a ScrumMaster), they are not their managers (the team is self-organized, fully responsible for their decisions), ScrumMaster is a coach, facilitator, helping the team to take ownership and realize they can solve most of their problems by themselves. And with every decision you take, there is a responsibility going hand in hand, and risk that you might fail. It is OK to fail if you learn from it. So ScrumMasters are not responsible for preventing failure, but for making sure the team will learn from it and figure out how are they going to work differently next time, so it will never happen again. And that’s very different from what the project managers have in their job description. And here is why – Project Manager is responsible for making decisions, ScrumMasters is not. It’s either the Development team (for how are they going to organize themselves to maximize the value towards the Sprint Goal), or Product Owner (for maximizing the value, prioritizing the backlog, and achieving the overall product success including the return on investment).

Agile is about safety to experiment and learning from feedback. In the VUVCA world, you never know what is the right functionality which will multiply the value and success. You need to inspect and adapt. Learn from failures. Be ready to respond to changes and be flexible to shift the direction based on feedback. Scrum has it all. Short Sprints which make it safe to fail, Retrospectives which ensure fast learning, Sprint Reviews which create a platform for frequent customer feedback, and Product Owners who take care of maximizing value and return on investment. It’s one thing to read it, and another to live it. What happens in your body if you hear “Your Sprint just failed.” Is it closer to the panic and looking for who to blame or is it closer to being curious and excited to search for improvements? It’s a simple question that indicates the level of agility. Failure is a good thing. All you need to do is learn from it.

New Scrum Guide

There was a new version of ScrumGuide published last week. And I have to say that I mostly like it. It’s lighter, less prescriptive, and simple. Here are a few differences.

#1 – Scrum Guide 2020 is Simple and Clear

Scrum Guide 2020 is clearer. Finally, there is a sentence that is easy to read, and that describes what Scrum is:

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

  1. A Product Owner orders the work for a complex problem into a Product Backlog.
  2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
  3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
  4. Repeat

Scrum is simple.

Yes, Scrum is simple and so the Scum Guide. It’s easy to read and understand. With this version, we got rid of many long and complicated phrases full of details. For example, one of my favorite changes in this space is that daily Scrum finally not suggesting the three questions but recommend that people “can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal…” Isn’t that awesome? After all those years of individual status meetings where people were reporting to someone what they did. It’s finally gone!

#2 – Focusing on the Mindset

I like the fact that the new Scrum Guide stresses the three empirical pillars of transparency, inspection, and adaptation and explains what are they about. The five values of Commitment, Focus, Openness, Respect, and Courage are clearly defined there now as well. It focuses on people’s behavior, over the processes and practices.

I also like the new Scrum Guide to remind us about the primary need for Agile and Scrum in complex and unpredictable environments: In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.” All over, if you know what needs to be done, can plan it, then all you need to focus on is how fast are you going to deliver it. In such a world all different estimation techniques, velocity, burn-down, and burn-up charts are considered useful. Unlike Scrum, which builds on empiricism and inspects and adapts the plans on the way.

#3 – Scrum Team Focus

The biggest change seems to be that we don’t have “Development Team”, ScrumMaster, and Product Owner but “Developers”, ScrumMaster, and Product Owner forming a Scrum Team together. It looks like a big change, but it’s rather cosmetic as they all have to collaborate and self-organize (or self-manage if you like) to maximize value towards the Sprint and Product Goal. So, no real change there, we’ve just finally got rid of the very typical dysfunction where the Product Owner was like an enemy and the team was delivering to the Product Owner only. Now there is no such mentality in the Scrum team, they are in it together, responsible for all product-related activities. They are a team in the first place, a team that is cross-functional so can deliver end-to-end value together. ‘Developers’ is a poor name, as most people somehow read it as software developers but it’s more like a product workers. They are still the people who create working product increment every Sprint, while Product Owner focuses on maximizing the value and ScrumMaster on improving teams and organizations.

I also like the new Scrum Guide to make the scaling approach clearer than before: “If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.”

#4 – Product Goal, Sprint Goal, and Increment

Finally, the last change is the new language about Product Goal (new) and Sprint Goal (improved), and Increment (clarified). All over the Scrum Guide is catching up with the industry and adding a Product Goal as an artifact. It also provides a definition of a product, which is much broader than many organizations think: “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract.” Product Goal is a long-term objective for the scrum team – a vision. Sprint Goal gives meaning to each sprint and defines the value we are focusing on now. The increment is a useful output. Well done, verified, and delivering value towards the Sprint Goal. Simple and straightforward. Finally, there is a much better language about the Definition of Done: “The moment a Product Backlog item meets the Definition of Done, an Increment is born.” It’s almost like a poem.

All over, I really like the new version. It doesn’t change much from what I was teaching and using, just brings a more clear and crisp definition of Scrum as I know it.

Great Product Owners

Great Product Owners are not only having business knowledge, authority and time, but also a few additional skills which people often don’t expect.

“Great Product Owner is a facilitator, coach, negotiator.”

You will usually hear about coaching and facilitation in the connection with the ScrumMaster role. So why do we talk about Product Owners and facilitation and coaching? Can’t they just use the service of the ScrumMaster? They can. However, in many environments Product Owners are not the ‘heroes’ who decide on everything. Quite the opposite. They are great listeners, who have respect for different customer voices, and their highest value to the system is they can find alignment through coaching and facilitation. Customers (users, stakeholders, shareholders, sponsors, …) never agree with each other, they all have their own preferences and needs. Great Product Owners can help customers to reconnect with their needs instead of pushing what they want. In order to be able to do so, they need to step back, acknowledge that their requests are representing just one way of achieving their goals, and search for other options that would satisfy the needs of more groups than before. In other words, they need to be good at integrative negotiation and finding win-win solutions.

Finally, the last skill great Product Owner needs is visual facilitation. It seems like an unimportant skill, but the good picture speaks for more than a thousand words and can create real magic in searching for alignment. Visualization creates transparency, and transparency is ground for accountability. You would be surprised how good visualization of a conversation and different perspectives can help people to change their mind and proactively help you in searching for alignment.

Maybe those skills are not on the top of the Product Owners list at the beginning, however, the same skills differentiate great Product Owner from the newbies.

10 Most Common Mistakes of Product Owner

Being a Product Owner is not simple. At the end of the day, Product Owners are responsible for the overall Product success. They need to have business knowledge, authority and time. But let’s have a look what are the typical mistakes of a Product Owner as this is one of the very common questions at the classes and learn from that perspective. Here is the list:

Doesn’t Have a Vision

Without a clear vision, there is no direction, no way Product Owner can prioritize, and no Scrum. It’s just a mess where all we can do is to say “everything needs to be done”. The key responsibility of the Product Owner is to have a vision and be able to share it with everybody. Agile organization is about having an evolutionary purpose. If you don’t have it, why are you even here? Similarly to the vision, we have a Sprint goal in Scrum. Without it, everything seems like a good idea to do in Sprint. Sprint goal helps us focus on the need, the real business value.

Can’t Say No

There is no way you can do everything. There are so many options in a complex world. So much functionality customers can ask for. The Product Owner who says yes to all wishes from the customers will fail as the quantity will burn out the organization. Instead, Product Owners are prioritizing based on the business value, and as 80% of value is hidden in only 20% of the functionality, they need to say no quite often during their prioritization.

Doesn’t Have the Business Knowledge

Business knowledge is wider than just a product understanding. It covers the understanding of customers, the market, and the competitive landscape. Without such deeper understanding, Product Owners can’t make a decision and are drafted by different stakeholder groups into their politic fights and the products are usually failing to deliver the real value. Product Owner doesn’t have to be technical, but the business knowledge is critical to their success.

Can’t Prioritize

Product Owner who believes everything needs to be done is not a Product Owner but customer or stakeholder. Prioritization is key in Scrum, at any time you shall know what is more important than the rest and what are we going to invest our energy (effort and money) into next and the rest later or never, depending on the feedback and impact we achieved by the value delivered. There is always more functionality which can be implemented. But maybe that little we already did is good enough for now and we can focus on some other more important areas. As I said already, 80% of value is hidden in only 20% of the functionality. There is no need to implement 100% of the ideas you have.

Don’t Have Negotiation Skills

The Product Owners without negotiation skills are very weak Product Owners. They often end us accepting everything customers ask for and are struggling to say no. Negotiation skill help Product Owners to understand not only what the users want but also what they need. Ant that’s the key part of the prioritization.

Estimates are the Key

Product owners who focus too much on estimates are mentally tight to the functionality, not the business value. In the traditional world, the estimates are important as all we care about is delivery, and we need to deliver more. In the Agile world, it’s not about delivering features. It’s about achieving certain business value. And those two have often only very little in common.

Doesn’t experiment

Product Owners who believe they can create a plan (in agile called Backlog) and then step by step execute it with the development teams during Sprints are not real Product Owners. Backlog can’t be farther from a plan and an iterative approach of delivery is here to inspect and adapt and learn from experiments. Find out where is the real value. The approaches like Lean Startup are quite useful here.

No Impact

As we said, Product Owner shall be able to run experiments. In a way, every backlog item is an experiment where you expect something will happen as a result. That’s the impact. Without knowing why you invest team time and energy into it, why to do it in the first place? Running an experiment without knowing how are you going to evaluate it is silly. That’s not an experiment but functionality you plan to deliver no matter what. Why? Because it’s important. Because I said so. Instead, spend more time identifying the impact so you know why you do it and what you expect to happen. Tools like Impact Mapping are quite helpful here.

Multiple Products

Or shall I say systems, or projects? Because product definition is much wider than that. Product Owners taking care of multiple product don’t have focus, and often don’t have time. Considering Product Owner is the person responsible for the overall product success including the return of investment, it’s quite useful to have the focus for making the product successful and don’t switch the context all the time.

Not Part of the Team

Product Owners sometimes feel they don’t belong to the team. They act as Backlog managers, telling the team what to do, and then waiting to get results/blaming at the end of Sprint. Instead of that, Product Owners are part of the Scrum team, they are team members, they shall collaborate with the team on delivering the value and achieving the Sprint Goal. They are part of the team.

Do we need CEO in Agile Organization?

Agile at the organizational level changes everything. I wrote here already about Agile HR, Agile Board of Directors, and Agile at the Executive Team Level. Let’s have a look at the top of the organization. Should it remain the same? Or shall we go one step further and change it as well?

Searching for an “agile mindset CEO” is frankly a nightmare. Everyone who tried it can confirm that. There are not many CEOs with enough Agile experience yet in the world and those few who has it are not likely looking for a job as they are usually quite happy in their current organization. So, no matter which executive search firm you choose, or what you write to the position description, the search firms are no real help here. Unless you already spent effort up front on growing the talent internally, you need huge luck to get someone who understands agile more than a basic theory. No matter how desperate you are searching for a CEO, this is still just a small obstacle, not the real reason for a structural change.

The real need for top-level change starts when most of the organization is having an agile mindset. The Agile transformation is about being agile. How many times you’ve heard this request: “How about if our management give us more support on your Agile journey?”, “How about if our executive team is Agile and don’t just push it to us?”, “How about if they practice the same way we work as well?”Would that make it a difference? Maybe. So why don’t we go one more step ahead and change from the top and become a role model for the entire organization? As the organization has changed and Agile is not solely the domain of the IT anymore, but the business agility got into every department, the need for a change at the top level is inevitable. Why do we need a CEO in the first place? Just because that’s how organizations always been? Shouldn’t we ‘eat our own lunch’ and change the way we work entirely? Shouldn’t we apply the same principles the team do? Sounds simple, right.

And as usually it is simple to understand, hard to do as it needs courage. Courage to say “We are going to be different.” We will have Organizational ScrumMaster and Organizational Product Owner instead of a CEO because it will be closer to the way we work at this organization, fits our values, and last but not least we believe it will help us to be more flexible and adaptive at the organizational level. And that’s worth of trying.

The Organizational ScrumMaster would be focusing on the right culture, mindset and structure, so we become high-performing innovative organizations which embraced agility, and Organizational Product Owner would be focusing externally to the business, vision a purpose to we know where are we heading and why and are value driven. Both roles need to respect each other and be open with each other, the same way as it is in a single Scrum team, as together they will be part of the Organizational Leadership Team, and the network structure of self-organizational teams. There are two roles in Scrum by a reason instead of one. When you ask people if they would suggest to combine them, no one feels it is a good idea. And at the top organizational level, we would still do it? The similar reasons are valid at this level as well. When you think about it, it fits the way we work much better, then a single CEO – supports the right organizational mindset, transparency, and collaboration, it is consistent with who we are.

From a legal perspective, it is perfectly possible, and it’s not that much work either. You might need to change the bylaws a little, but there is no reason why you can’t do it. From a hiring perspective, it’s much simpler, as you are not looking for that ‘superhero’ personality who would be great with both internal and external sides. Try it. As I said already, all you need is courage. And that’s one of the Scrum values anyway. Experiment, and from that stage inspect and adapt. Now, do I believe that this SM-CEO or PO-CEO will eventually make themselves out of job? No, I don’t. It’s the same as the team level. Even if the team is self-organized and knows the business well, there is still work for ScrumMaster and Product Owner. Similarly, at the organizational level, there is still a need for Organizational ScrumMaster and Organizational Product Owner even when the network of collaborative teams got self-organized, business value-driven, and customer-centric. The Organizational ScrumMaster and Organizational Product Owner would use Leader – Leader style to build other leaders around them, and if they are successful, the organization will become purpose driven where leadership will be emergent and structure liquid. The same way as it is in the Scrum team, the Organizational ScrumMaster and Organizational Product Owner will move from those who explain, tell and share, to those who coach, facilitate, and keep the system spinning. And that’s what is the Agile Leadership about.

Five books every Product Owner should read

To continue my with my book recommendations (check the five books every ScrumMaster should read, and five books Agile Leader shall read), I have several books here, I would recommend every Product Owner to read. It’s a mix which will help you to understand Agile Product Ownership, Discovery and delivery process in much broader perspective. Enjoy reading 🙂

  1. Impact Mapping: Making a big impact with software products and projects is a practical guide to impact mapping, a simple yet incredibly effective method for collaborative strategic planning that helps organizations make an impact with software. Impact mapping helps to create better plans and roadmaps that ensure alignment of business and delivery, and are easily adaptable to change. Impact mapping fits nicely into several current trends in software product management and release planning, including goal-oriented requirements engineering, frequent iterative delivery, agile and lean software methods, lean startup product development cycles, and design thinking.
  2. Agile Estimating and Planning is the definitive, practical guide to estimating and planning agile projects. In the book, Agile Alliance co-founder Mike Cohn discusses the philosophy of the agile estimate and planning, and shows you exactly how to get the job done with real-world examples and case studies. This book is a must-have agile estimation tool for your development toolbox.
  3. User Story Mapping: Discover the Whole Story, Build the Right Product shows you how changeable story maps enable your team to hold better conversations about the project throughout the development process. Your team will learn to come away with a shared understanding of what you’re attempting to build and why. This insightful book examines how this often misunderstood technique can help your team stay focused on users and their needs without getting lost in the enthusiasm for individual product features.
  4. Innovation Games®: Creating Breakthrough Products Through Collaborative Play is a must-read for anyone involved in market research and product or service development (which, when you think about it, means virtually everyone). Innovation is incredibly simple. All you have to do is accurately predict what your customers want, need, and will pay for. Oh, wait. Sorry. That’s actually very hard. At least with traditional tools. So how do you find this information? Well, you can just ask your customers what they want. The problem, of course, is that with most truly breakthrough innovations, current and potential customers don’t actually know what they want before they see it. If you just try to deliver what they already want, you’ll never truly innovate. Even worse, traditional market research practices prove that often, customers have trouble articulating what, exactly, they want in the first place.
  5. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses is about a new approach being adopted across the globe, changing the way companies are built and new products are launched. The Lean Startup approach fosters companies that are both more capital efficient and that leverage human creativity more effectively. Inspired by lessons from lean manufacturing, it relies on “validated learning,” rapid scientific experimentation, as well as a number of counter-intuitive practices that shorten product development cycles, measure actual progress without resorting to vanity metrics, and learn what customers really want. It enables a company to shift directions with agility, altering plans inch by inch, minute by minute. Rather than wasting time creating elaborate business plans, The Lean Startup offers entrepreneurs – in companies of all sizes – a way to test their vision continuously, to adapt and adjust before it’s too late.

User Story as a Card

User Story is one of the most common formats how to write Product Backlog Item. It has specific format which forces people to focus on business value.

As a [user | role| persona]
I want to get [functionality]
So that I get [business value]

As an example of such User Story for my online beer store called “Berrer” we can write the following:

As Jon (busy manager with no time)
I want to get beers selected by “Beerer”
So that I can impress my friends by variety of rare brands.

It shall give us three different information – Who, What, and Why – which must fit together and once you read it to someone it shall create consistent story together. As you may have noticed the User Story looks at the functionality from the business perspective and is customer centric (note that customers are all user, stakeholders, other teams, … ). We never define how exactly it shall be solved, but describe the business impact we want to achieve.

Write Acceptance criteria was never good idea

Having that definition, companies are often missing the place where to write the exact specification. But there is none. It’s all about conversation. It should fit a small index card. Having said that, teams are still fighting and try to keep it as close as possible to the traditional detailed specification. One way how keep it close is to add detail as Acceptance criteria. It usually looks as checklist of all possible details you shall/shall not implement. It seems to be useful for teams who have limited understanding of business and product but it’s not. To give you an example of such Acceptance Criteria for the above defined User Story, it can look like this:

  • Beers from all continents
  • At least one beer from Belgium
  • Several small local breweries
  • One light, dark, Ale, Pils

As a result of it development team is not involved in the story definition anymore. They just take those points one by one and implement it. If it’s not working as we missed something, it’s not their fault but the Product Owners’. He shall have made the missing piece part of the Acceptance criteria. So let’s have a look to better solution.

Define Conditions of Satisfaction instead

As we said before, User Story is about conversation. It shall be simple, clear, and easy to remember. If you write well so it is small enough, there is no need for any additional information at the back side of the card. However sometimes you might find it useful to stress certain expected behavior / impact. In such case we turn the User Story card and write the Conditions of satisfaction. For the above defined story it might be:

Jon can impress his friends by selection of all different tastes of beer selected from micro-breweries across the world.

As a result of this the team is focusing on solving user problem instead of implementing what was defined before. The implementation usually starts with conversation. How can we deliver the more value with less effort? What is the minimal functionality we have to deliver? How can we address his needs? We need everyone involved, everyone interested, and everyone understand the overall business, personas, their needs and their dreams.

It may take bit longer at the beginning, but it’s worth investing the effort as the committed team which is living by the product can always come up with better solution then one Product Owner.

Writing Acceptance criteria is our legacy from traditional world, while defining Conditions of satisfaction is very Agile. Agile and Scrum is mindset. If you have it, it doesn’t matter how you write your User Stories because you already understand the fundamental difference. It’s about value to be delivered to the customer, instead effort, items delivery, and velocity. If you don’t, changing only the label won’t help. You would have to significantly change the way you think about Backlog items and that might be very painful and long process where User Story format with Conditions of satisfaction will help. I went through that change with several companies during Agile Coaching and it was always worth of the effort. If you want to get bit more practice, I also teach it at CSPO – Certified Scrum Product Owner class.

Product Owner is an investor

Product Owner role is usually more understandable for companies that the ScrumMaster role. After all, companies have someone responsible for the product or business. So that’s the candidate. The problem starts when we deep dive into the role understanding and find out that Product owner shall not only understand the business but needs an authority to say “NO”. If you don’t, we mostly end up being late, with stress and low product quality.

How the Product Owner shall decide on priorities and how shall they know when to say “NO”? Overall it’s simple. Apply simplicity rule. It’s already in the Agile Manifesto as one of the principles. ‘We maximize the work not done.’ It has its roots in the research saying that 60% of a successfully delivered product is never or rarely used. So why do we keep investing into those features. Isn’t it waste? It is. But it’s hard to say no, so Product Owners keep prioritizing those features. Instead they shall act as investors and evaluate if the expected benefit will be paid off. If yes, do that. If not, let’s start a conversation or a negotiation with the customers about what else can we do to help them with what they need. The functionality they asked for are just one option how to achieve it.

Who is the great Product Owner?

  • The great Product Owner is an investor – imagine you would invest your own money into functionality you prioritize for the next Sprint.
  • The great Product Owner must have an authority to say NO.
  • The great Product Owner must be good at communication, always search for another option how to deliver maximum value to the customers with least possible effort.
  • The great Product Owner shall understand that your customers (internal stakeholders, users, … ) have wishes. Those wishes often contradict with each other so you can’t make them all even if you have unlimited resources. It’s up to you to decide where the highest value is, and skip the rest.
  • The great Product Owner must have business knowledge about the product and understand the customers – it’s not a technical role.
  • The great Product Owner shall have a time to spend with the team to build good relationship with them, and to make sure your team understands the purpose of the product/release/Sprint.

If you don’t have all those, don’t worry. But eventually that’s who you shall become as a Product Owner.

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.