Poor Backlog - too complex to refine
Hi all, I've started a new job and I've been thrown in at the deep end. I am implementing Scrum, as this has been very successful for me in the past. The current PO is taking a step back, so I am onboarding a new complex business with an pre-existing Dictatorship leadership/dev approch who want to get better (I have buy-in from the grownups).
My main challenge is the backlog and the complexity of the system
- Nothing is refined
- Poor documentation
- Little knowledge within the team (some GREAT devs, but they've been protected and spoon feed)
As PO/Tech-Leader I am unable to get the backlog refined in time for Sprint Start.
Therefore, we are having to Refine and pull tickets into the active Sprint. I don't seem to have the time to refine the tickets to the point where the developers are happy to point them (self included).
We are currently doing 4 hours of refinement every week! This is very draining for the team and not something I think is sustainable.
I am looking for any advice..
As PO/Tech-Leader I am unable to get the backlog refined in time for Sprint Start.
As you mentioned you have started a new job, do you think your are lacking knowledge regarding the product and you need to rely on the team to help you with the refinement? May be you could work on getting a better understanding of the product you are dealing with.
I don't seem to have the time to refine the tickets to the point where the developers are happy to point them (self included).
Refinement can be done by anyone on the team and it need not be the sole responsibility of the PO.
Also do you have a Scrum master in your scenario and did you reach out to him for help?
The biggest problem I see is the team's lack of knowledge. As you're seeing firsthand, it's risky to shield the team from the business, stakeholders, and product-level decisions. Investing in this knowledge will have a significant impact. Not only will the whole team be more capable of being involved in refinement, but they'll have answers to some questions without needing to ask them and be able to ask better questions about the work. A broader contextual understanding can also help to inform technical design decisions and improve testing from the user's perspective, increasing overall product quality.
It's not usually popular, but slowing down the delivery of new work to build knowledge is helpful. This isn't just an opportunity for the developers to gain knowledge. Once everyone has a baseline knowledge about the business, stakeholders, and product, I'd suggest that you, as the Product Owner, go deeper into these topics. At the same time, the developers look at the technical state of the product. Since it sounds like technical decisions could have been made without understanding the context, I'd be concerned about inadvertent technical debt that will impact future work.
This will help you reach the state where refinement is a whole-team activity that can be done more effectively and efficiently. However, it also means that, at least for a while, you will have to put in more than four hours a week into this effort.
Best thing to do is to begin refining, utilizing the knowledge and and experience in hand.
Don't expect immediate success, but consistent exercising and practicing will bring team onto new level
If needed and possible make Sprint duration shorter, so refinement would be more frequent. If developers have deficit of time, make refinement meetings shorter, 15 min. or so, but frequent. Facilitate learning about refinement as often as possible, using videos, visuals, examples. There are lots of free resources at this website by the way.
Don't micromanage refinement, let developers and scrum master do it on their own. Just don't except the idea that "this cant be refined". Any data and story in the world, even the screenplay for Aquaman or news article at NY Post can be refined into product backlog.
I am onboarding a new complex business with an pre-existing Dictatorship leadership/dev approch who want to get better (I have buy-in from the grownups).
That's nice, but do you actually have a sense of urgency from them that things need to get better? Is that message being communicated and reinforced, so change becomes more important than the day job?
The seeds of success are sown in timely and judicious Product Backlog refinement. It is not unreasonable to spend around 10% of the time during a Sprint on refinement activities -- more if needed.