Skip to main content

How can we improve our sprint planning meetings?

Last post 12:27 pm September 3, 2019 by Thomas Owens
8 replies
08:28 am September 2, 2019

In our planning meetings we frequently fail as a development team. We can not predict how can we make the product or product backlog. So every sprint we are facing unrealized development which is not spoken in our planning meeting. Which technique can be used for much effective planning?

 

P.S we are making planning poker. Also we are discussing on each item in an empiric environment.


09:15 am September 2, 2019

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?


11:48 am September 2, 2019

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?


01:32 pm September 2, 2019

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

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

 


02:23 pm September 2, 2019

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.


05:27 am September 3, 2019

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.

11:02 am September 3, 2019

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.

 


11:11 am September 3, 2019

Hi Ian,

 

Thanks for the link. I will investigate deep down.


12:27 pm September 3, 2019

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.