Skip to main content

Timeboxes in the refinement

Last post 03:07 pm July 10, 2016 by Michael Kogan
5 replies
06:49 am July 2, 2016

Hi All,

I am working in a scrum team as a developer and in our team we have a disagreement about timeboxes in the refinement sessions. I would like to have your opinion on both the approaches.

Our business analyst is timeboxing all stories in the refinment (om 10 minutes). He expects the team to estimate the story, after the timebox is over.

In my opinion that is not how it should be done. If there is still discussion or open questions after the timebox has passed, we are not yet able to estimate the story. Then we have two options:
- Keep on discussing it, until all is clear and completely ignore the timebox
- Move on to the next story without estimation for this story and the business analyst/product owner/stakeholders should (with the input from the refinment session) improve the quality of the story, so we can discuss iit in the next refinement.

I would like to hear what your opinion is on this situation. And of course are any tips welcome :)


05:45 am July 6, 2016

The Time box events are:
1) Sprint Planning
2) Daily Scrum
3) Sprint
4) Sprint Review
5) Sprint Retrospective.

If you cannot estimate then you cant do sprint planning and not even the Sprint will get over with most of stories being incomplete.
To be on safer side then the development team should include only those stories which are estimated with definition of done.


07:22 am July 6, 2016

Why isn't the Product Owner able to explain the items on the Product Backlog during Product Backlog Refinement?

If he or she needs the help of the Development Team to create PBI's which they *can* estimate, then the whole team should give their assistance.

It also sounds as though "Business Analyst" is a role in this case, and an antipattern which ought to be addressed.


12:20 pm July 6, 2016

It is not up to the BA to decide how much time is spent on refining an item, it's a team decision. The team need to have an understanding of what the PBI entails to be able to estimate it.
Possibly the BA need to prepare PBIs better before discussing them in refinement. I assume the BA either the PO or a member of the dev team? Generally, I think time-boxing is good. It helps keep focus and help you prevent waste. If your refinement sessions take forever you need to discuss why and consider how this time might be reduced. Scrum is quite clear that roughly 10% if the time in a sprint should be used for planning activities such as refinement.
One technique that you might try is to time-box the discussion for e.g. 5 and after that the team votes (fist to five or similar) if they need to discuss the item further. If yes, continue the discussion for another 5 minutes, if no estimate and move to the next item.
This forces the team to consider if they know enough to estimate or not. In my experience, items are often discussed in too much detail before they are estimated which is wasteful.


01:07 pm July 6, 2016

Key purpose of Product Refinement/Grooming meeting is to -

1) Bring more clarity to PBI/Story in order to bring it closure to "ready" state

2) High level estimates( story points) as per the collective understanding of the participants/team basis "Relative Complexity" for the PBI/Story.

3) Identification of gaps/questions around the PBI. PO should then take away those questions/gaps and work to have them answered. Development team can play a major role by helping the PO in highlighting gaps/questions from functional and business value perspective (catch - Care should be taken that questions/gaps do not get drifted/biased from technical/solution mind set)

Refined stories (in accordance with Team's definition of "Ready") are taken as input for Sprint Planning meeting! Sprint planning meeting also provides opportunity ratify, validate and refine Estimation (Story Points) against each prioritized PBI.




03:07 pm July 10, 2016

Hi Micha,

As Rishi mentioned above, refinement meetings are not time-boxed, though they should not take more than 10% of a team's capacity. Looks like you BA is using time-boxing as an anti-overloading medicine :-).
You don't have to come up with estimations at the end of refinement meetings - these are required at the Sprint Planning event. And you cannot refine forever either. The recommended way is to refine in more details the items that are high on the backlog and less details for those which are lower. There is a possibility that the problematic user stories are too complex in which case the PO (sorry, the BA :-)) should invest some more in slicing them thinner.

Hope this helps,
Michael


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.