Skip to main content

Accounting for UAT team-only system work

Last post 01:11 pm March 21, 2018 by Filip Łukaszewski
2 replies
07:57 pm March 20, 2018

Background:

- One of my teams has a DoD that includes UAT. 

- Our UAT team is a group of 4 system administrators. 

- Our "product owner" is a group of technical account managers (TAMs) who are the liaisons between our clients' IT teams and our development teams.  They have a previously agreed to limit of 75 points per sprint that the team can commit to (this was an agreement prior to me becoming the ScrumMaster of the team - I am working on changing this so the team can commit based on capacity for that sprint, but I'm not there yet.).  

Issue:

In addition to performing UAT as the last step in our development process, our system admins have to manually set up new clients within our system.  Our technical account managers (TAMs) create a card in JIRA and attach all the necessary information for the setup in the card.  The system admin then estimates that setup (usually a 1 or 2, depending on how much configuration is needed in the system) and then we pull that work into our sprint during sprint planning based on the TAMs' prioritization. 

We are now being asked to not estimate that level of effort because the TAMs don't want a UAT-only task to take away from that 75 points the team has agreed to commit to.  My stance is that the system admin folks that do UAT are part of our team and UAT is part of our DoD, so any of their work for our team (whether it's testing stories or doing these manual setups) impacts their capacity and needs to be accounted for in sprint planning and in our sprint forecast.  

I am a fairly new Scrum Master and haven't encountered this type of interference into how the team plans its work before.  Am I right to push back and defend the team's decision to estimate and include these UAT-only tasks in the sprint? 


09:56 pm March 20, 2018

Am I right to push back and defend the team's decision to estimate and include these UAT-only tasks in the sprint? 

Yes, up to a point. Given the other things you have said though, I'd question if that is the battle to be fought.

  • What, for example, does the Scrum Guide have to say about product ownership being represented by a committee?
  • Why is commitment being framed in terms of points rather than Sprint Goals? What purpose does sprinting here actually serve?
  • Why are people outside the Development Team deciding what sort of commitments the team can and cannot make?
  • What evidence is there that teamwork is happening at all? Do members understand that the team must create a "Done" and tested increment every Sprint, and can they self-organize accordingly? If not, why not?

01:11 pm March 21, 2018

I think you have to make a decision: are admins doing UAT part of the scrum team (in which case 75 points also should to include their work), or not - and then remove UAT from DoD. Or stop calling it Scrum :/ Such decision must be transparently communicated to TAMs.


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.