Planning vs. Refinement

Last post 12:37 pm September 16, 2021
by Balaji Dhamodaran
9 replies
Author
Messages
03:38 pm January 16, 2019

Question - in the vast majority of places I've worked, estimating user stories has been done during planning sessions. I know there's a train of through that estimating should be done during refinement, so why do so many people estimate during planning sessions? From my perspective, refinement should entail some or all of the team assessing the product backlog items for 'readiness' for the sprint. By that, I mean in terms of INVEST criteria, acceptance criteria, etc, but not including estimates. If your refinement session is going to include estimating, then you need the whole team there. When planning starts, the PO will present the pre-refined, pritoritsed backlog to the team, we will discuss, estimate, etc., then that forms the basis of our sprint backlog. We of course assess capacity for the coming sprint, etc. And in the big scheme of things, if different people are approaching estimating in different ways, is there really a right or wrong way (given that everyone involved in scrum has a different opinion!)?

05:56 pm January 16, 2019

why do so many people estimate during planning sessions?

When you see this happen, would you say that the teams involved have a good understanding of what it means for work to be “ready” for Sprint Planning?

02:42 pm January 17, 2019

Ian's coaching style just nails it all the time. His question captures the essence.

 

I'm not as experienced as him, so I'll have to present my thoughts in phrases :)

Yes, estimating stories can be done during sprint planning, and there's nothing wrong with that. However, in doing so:

  • the entire team needs more time for the planning session: DT to estimate, PO to possibly reorder the backlog and come up with a new vision, DT to pull what they think they can achieve, team to draft a sprint goal, DT to break down some work in order to start, etc
  • stories that are critical to the business (PO) could be left not estimated (or estimated at really high numbers) due to the DT's lack of understanding, or due to more conversations required, or advice needed from others (domain experts?), or dependency being identified, or solution impossible to implement, and so on
  • the PO would not have an accurate understanding of the backlog and, therefore, the order would not be the most appropriate one
  • there would more time required for the meeting, which, in turn, would lead to less focus, more fatigue and reduced productivity. Keep it simple.
  • and I can go on

 

Hence the practice of having conversations (backlog refinements) before the sprint planning. Note, however, there's no exclusion in place: that is, estimating during sprint planning doesn't exclude estimating during refinement; viceversa, estiamting during refinement doesn't exclude estimating during sprint planning.

All evidence points out it is way better to have the bulk of the estimation done in backlog refinements. And, of course, if there are new requests from the business (say an urgent insurance regulatory fix for an issue that was just discovered and said fix needs to be applied otherwise massive fine's going to be applied), those would of course have a place to be discussed - and estimated - during sprint planning. 

04:00 pm January 17, 2019

I echo @Eugene's comment on @Ian.  I am learning a lot from his Yoda like responses. Good thing he has a picture on his account or I would be picturing Yoda as I read his responses.

Both @Ian and @Eugene are correct with their answers. I've worked with teams that have done both and one team that actually did both at the same time.  It boils down to what the team feels is the best way to accomplish the task of estimating the work that will be included in the Sprint.  Yes, there is the "no estimate" movement but I'm not going to get into that beyond saying when a team of mine tried, they went back to estimating after 2 sprints. 

One thing I always point out about estimates are they are not much more than educated guesses so do not read more into their value than their use for getting some idea of what the team feels that they can get done. 

09:38 pm January 17, 2019

"estimates are... not much more than educated guesses so do not read more into their value than their use for getting some idea of what the team feels that they can get done"

Exactly!

 

04:22 pm September 15, 2021

So, in the Planning Meeting it is good practice to only ESTIMATE (Planning Poker) PBIs that have already been refined or only refine PBIs that you want to include in the Sprint but, for some reason, have not had time to refine before. Is this correct? 

Thanks!

06:59 pm September 15, 2021

I can't say you are wrong @Joan Moreno i Maurel but also can't say you are right.  This is something that your team needs to decide.  

I do, however, coach that you make every effort to refine items prior to Sprint Planning.  The goal of Sprint Planning is to pull the items from the Product Backlog that the team understands well enough to believe they can be done during a sprint.  There are times that something in the Product Backlog that the team has not had adequate time to refine might be included.  There are also times that something newly discovered could lead to the need to add a brand new item.  But those should be the exception and not the norm.  Those activities increase your risk of successfully delivering increments of value and could hinder you from being able to react to information gained while doing work that you felt you already understood.  They also impact your consistency of work delivery.  The more you can approach a sprint with a confidence that you understand the work, the better suited the team will be to reacting to new discoveries while doing the work.  

07:25 pm September 15, 2021

So, in the Planning Meeting it is good practice to only ESTIMATE (Planning Poker) PBIs that have already been refined

Can a team refine items, and thereby make them Ready for Sprint Planning, without estimating how much work will be involved?

or only refine PBIs that you want to include in the Sprint but, for some reason, have not had time to refine before. Is this correct?

There is a need to refine work and make it Ready before the Sprint Planning event commences. There's nothing to stop this from being done immediately beforehand, and it does not necessarily have to be taken care of in a separately arranged meeting.

Bear in mind that the Sprint Review is a formal just-in-time opportunity to ensure the Product Backlog is in the best possible shape before Sprint Planning.

06:42 am September 16, 2021

Daniel Wilhite and  Ian Mitchell thank you very much for your fast replies! :)

After your answers, I still think that refining in the Planning may be too late in some cases, it will be better to spend a little more time refining and estimating during the Sprint, and the Planning will surely take us less time than the maximum of 4h (in two weeks Sprints). We will do it like this to start.

12:37 pm September 16, 2021

Joan Moreno i Maurel Refinement is an ongoing activity during the sprint. Activities like breaking down the product backlog items to smaller and precise items, adding details like description, order and size making it 'Ready'  for sprint plannning. Yes it helps to keep the sprint planning within timebox.