Skip to main content

Dealing with day-to-day tickets vs projects

Last post 07:39 pm March 19, 2018 by Martin Cella
3 replies
01:16 am March 12, 2018

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!


11:30 am March 13, 2018

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?


07:23 pm March 13, 2018

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.

 


01:53 am March 18, 2018

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.


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.