Small size team (14 devs) - Backlog refinement sessions taking too much of dev's time
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!
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?"
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."
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.
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.
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 ;-)
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?