Dealing with day-to-day tickets vs projects
Hi guys,
I am new to this site. I have recently entered a software company and I coordinate a team of 5 Product Owners. The first thing I noticed in my very first week is that Product Owners are dealing with different projects at the same time, but also, several day-to-day requests are added during each sprint, due to the ever changing environment we work.
What would be a good solution to deal with this? Should I allocate a team to deal with day-to-day requests and another to deal with projects?
As well as this, due to the large amount of requests, Product Owners are overloaded and end up doing lot of task during the day, which results in unclear product requirements, projects put on hold, long working days, etc...
Thanks in advance!
Are the Product Owners taking care to ensure that all new Product work which emerges is accounted for on the Product Backlog, and that the Development Teams are adequately engaged in refining it to a "ready" state? Meanwhile, are the Development Teams taking care to ensure that work is not pushed on to them during a Sprint, and that the Sprint Backlog is only revised if it helps them to meet the agreed Sprint Goal? Also is the Sprint cadence sufficiently brisk to meet the needs of the business, and is the Definition of Done sufficiently robust to keep product development stable?
To echo Ian's comments, care must be taken to ensure that work is never pushed to the Development Team during a sprint, and that the Scrum Master protects the Development Team and their Sprint Forecast from such intrusions.
That approach does not help when feature work is intermingled with run-time support for the same product. Rarely will a support request or issue fit into a Scrum cadence of refinement/offer/forecast/delivery at whatever sprint length is being practiced.
In my opinion, a better practice is to have a separate group/team manage the day-to-day support requests, thereby shielding the Development Team from such work. I have actually participated as a SM in a practice where a group of Development Teams rotated into a support role for a 2-sprint stretch, and shielded the other Scrum Teams from such requests. These support teams often provided a much smaller forecast based on the expected time needed for support activities, and they would pull items throughout the sprint as their capacity allowed.
One unanticipated but significant benefit to this approach was the knowledge gained from the team swarming around each support item as it was received. Every team placed into this support role came out of it with significant cross-training and understanding of a variety of systems, making them stronger going forward.
Thanks a lot guys! Yes from what I could see, there are 2 main issues here... 1- The Business is very demanding, and daily request/bugs tend to come very often. 2- Knowledge in the Dev team is concentrated in very few members. Most experienced guys have most of the knowledge, and almos no knowledge transfer is carried out. My idea, apart from doing training sessions in order to carry out this knowledge transfer, was to allocate some team members to deal with day to day requests, while leaving other part of the team to deal with Sprint items and projects.