Skip to main content

What To Do About All That Support

Last post 07:47 am March 13, 2018 by Ian Mitchell
1 reply
09:05 pm March 12, 2018

Here is the scenario.  I am a product owner of a team that that consists of 4 developers, 2 QA resources, and 1 user acceptance tester.  We have become extremely proficient at working together and the team simply runs as a well oiled machine.  We have done so well, that the company has run a few pilots of automated tasks on our team because of our organization.

 

The problem we are having is applications that are required to support our development that reside outside of our release train are not truly working with scrum.  They are insisting that they create user stories within our features for testing support and production support.  My team has embraced removing points out of our sprint capacity to deal with support issues so that our velocity/capacity is a true representation of development work.

I do not believe that they should be adding stories under a feature not owned by them and when they consistently miss deliverables it is destroying our metrics. 

Are there any best practices or suggestions that you all can point me towards so that I can demonstrate how much more efficiently their team will work?  Thanks in advance, and if you need any followup info, please let me know.


07:47 am March 13, 2018

If each increment must be supported in some way following release, shouldn’t the qualities required for that support be included in the Definition of Done?

If “support” includes defect fixes or the repayment of technical debt, then that work ought to be conducted by the Development Team. Reserving Sprint capacity to do so, however, would be sub-optimal. The amount to reserve cannot usually be anticipated accurately, and the act of doing so causes transparency over undone work to be lost. It would be better to add support issues to the Product Backlog so the amount of work remaining can be properly accounted for, assuming they aren’t critical incidents, or not trivial enough to be absorbed and resolved in the current Sprint.


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.