How can we improve our sprint planning meetings?

Are the team are allowing enough time for Product Backlog refinement? Also, do they have a clear understanding of what it means for work to be "ready" for development?

Hi Ian,

We have also refinement meeting in each week. To be honest we never discuss about being ready for the development. But to be ready for the development would you suggest anything to us,any special method or quetions or preparations?

Some teams choose to implement and observe a Definition of Ready:

https://www.scrum.org/resources/blog/walking-through-definition-ready

Can you tell more about what you do at your refinement meetings, such as how much time you spend, who participates, and how you go about refining your Product Backlog Items? Many problems associated with Sprint Planning come from insufficient or ineffective (or sometimes both) Product Backlog Refinement. It would be good to take a good, hard look at everything around Refinement.

Hi @ezgi,

Could you provide little more detail on the issue. There are many suggestions I would like to provide. Your problem could not be in planning meeting but somewhere else

• Discuss with your team what could be the root cause? (5 Whys technique)
• Have a one to one discussion with your team members and find what motivates them or what is holding them back? In my experience, giving low level technical task to an experienced developer was a demotivating factor due to which he stopped giving his insights to the team.
• Evaluate your team on scrum values and pillars. Is enough transparency being maintained? Do your team members respects each other? etc
• I would also suggest you to read Five dysfunctions of the a team. It may give you some idea to proceed further.

Hi Thomas,

We spend 1 hours in each week to refine two different story. our sprint is 2 weeks. So in a sprint we are making 2 hour refinement and totaly refine 4 user story. In planning and refinements are seems to be ok. they are discussing 'how' but in sprint they say this implementation has to be done also. So they add different sub tasks, also they face with unpredicted problems. As a consequence our sprint is failing, and we can not accomplish even a single usery story.

Hi Ian,

Thanks for the link. I will investigate deep down.

We spend 1 hours in each week to refine two different story. our sprint is 2 weeks. So in a sprint we are making 2 hour refinement and totaly refine 4 user story. In planning and refinements are seems to be ok. they are discussing 'how' but in sprint they say this implementation has to be done also. So they add different sub tasks, also they face with unpredicted problems. As a consequence our sprint is failing, and we can not accomplish even a single usery story.

A few things stick out.

This doesn't seem like enough time in refinement. The Scrum Guide says that "Refinement usually consumes no more than 10% of the capacity of the Development Team". Note that unlike other events, this is not a timebox. I would expect a Scrum Team with a Development Team of 3 to be spending about 15-20 hours doing refinement activities per Sprint. I'd get worried if the team of this size was spending 12 or fewer or more than 25 hours doing refinement on a regular basis. For larger teams, I'd expect more time to be allocated to refinement.

If you claim to be totally refining 4 User Stories, yet the team is still adding work that needs to be done, then the work isn't totally refined. During the time spent in refinement, the team should be splitting Product Backlog Items into thin vertical slices of work, adding all of the details, identifying hard or soft dependencies to items in the Product Backlog, and communicating some estimate or effort associated with each Product Backlog Item. If you get to Sprint Planning and you're still doing this or it hasn't been done, there hasn't been enough refinement.

Looking at a fixed number of User Stories or Product Backlog Items also seems to be a hinderance. Sometimes, you need to look at a good chunk of the Product Backlog to understand relationships between the most valuable work at the top and upcoming work. Sometimes, that less valuable work further down the backlog may inform how you go about some of the work today in order to avoid introducing the need to perform rework. The level of clarity increases for items at the top of the Product Backlog and decreases as you move down, but that doesn't mean that the team is unaware of the top portions of the Product Backlog.

I think that you should spend a lot of time looking at your current refinement techniques and learning how others do refinement. If you improve refinement, I think you'll have a much easier time at Sprint Planning. If you can focus more on the planning there, you can more accurately plan your 2 week Sprint.