Skip to main content

Small size team (14 devs) - Backlog refinement sessions taking too much of dev's time

Last post 07:42 am February 7, 2024 by Martin Jungmair
6 replies
04:32 pm January 31, 2024

Hi all,

I wanted to ask how everyone is handling backlog refinement sessions in a relatively small size team?

I am only doing one hours sessions before 3 week sprint, and still, I feel like the team spends to much time on it and might not take any value out of it. The company has high expectations on how much work needs doing, if I take their time away in these sessions, it is less time they have for development. 

Any tips for effiencies gain or any other tips in general?

Thank you! 


06:26 pm January 31, 2024

The company has high expectations on how much work needs doing, if I take their time away in these sessions, it is less time they have for development. 

Do they have any expectations on how well it needs doing? Product Backlog refinement is the art and science of making work ready for Sprint Planning. When the Developers enter Sprint Planning, the question should never be: "Can we do this work?". They already know they can. The question is: "Should we? Should we do this work to meet a meaningful Sprint Goal that mitigates a significant risk or uncertainty?"


06:34 pm January 31, 2024

Small size team (14 devs)

Also, have they self-organized into a team of that size? The Scrum Guide says:

"Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people."

 


06:40 pm January 31, 2024

Spending 1 hour of refinement every 3 weeks is, in my experience, very little. In my experience as both a Developer and in coaching teams, each person spends about 4 hours per week refining, on average. There may be weeks where people spend a little more (5-6 hours) or a little less (2-3 hours). Rarely does a week go by where people don't refine.

Without understanding more about your context and the risk appetite for the team, the broader organization, and the stakeholders, it's not easy to say how much refinement you should be doing. An environment that is less tolerant of ambiguity and risk will likely spend more time refining a smaller amount of work so that way they are more confident in the clarity and understanding of requirements. However, an environment that has a large amount of change and uncertainty won't be able to refine as much, since refining work that ends up being invalidated or deprioritized is waste. The experience of the team is also a factor, as a team that is more comfortable in the domain and with the tools and technologies being used will be able to make higher quality decisions on-the-fly and can spend less time refining early, before the work is planned and started.

If you want more concrete advice, you're going to need to provide a lot more detail about the specific problems.


12:28 pm February 1, 2024

Your Sprint length is 3 weeks. Here is the way you could try it

In General, Min 4hrs and unto 8hrs should be consume in a Sprint cycle for Refinement Session. We could divide or Spilt into multiple refinement session as needed (If I were you, I will have two or three refinement sessions in a sprint length ( each week upto 2hrs).

This helps to BA/Agile team of they wanted to do any analysis allows sometime to do so and will gather next week to review and finalize the DoD/DoR. 

Purpose:  Goal Is to consistently maintain a minimum of two sprints worth of stories that are ready to work. This allows the team to have a ready supply of work to pull in at any given time should priorities shift.


03:50 pm February 6, 2024

With a sprint lenght of 3 weeks, with our Scrum Team, i plan always 2 hours by week.

If necessary, we can extend and plan another 2 hour refinement if not ready for next sprint, but we can cancel if not necessary....

I suggest to plan a recursive meeting for refinement and adjust your team velocity projection with that...

With a proper refinement, the sprint planning is more easy ;-)


07:42 am February 7, 2024

What is the definition of "dev time" in your company? Are your developer just coder or should they have the capability to build a solution? A coder is part of a feature factory and implements a clear requirement with in the PBI predefined solution. A developer who builds a solution gets just the WHY and WHAT and decide HOW to implement it. The difference between these option is essential to answer your question. 

Assuming the second option, how can you check functional and non-functional requirements for all tickets of 3 weeks for 14 devs in one hour? Are the tickets then ready to start with them?


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.