Skip to main content

Hit Plateau in 2nd Year of Scrum! Need ideas!

Last post 05:24 am April 30, 2015 by Christian Geyer
5 replies
04:07 pm April 10, 2015

Hello! I am the CSM for a non-profit with a small team of developers and testers. As with a lot of non-profits, we are understaffed and have team members pulled in multiple directions to cover everything needed. In our 1st year of implementing scrum, we had a fair amount of success and saw definite improvements in comparison to the team's old waterfall methods!

Now, that we are in the 2nd year, we seem to have hit a massive plateau and have not reached our sprint goals in the last 4 sprints. The bottleneck seems to be UAT. The users that are doing UAT are very understaffed and do not have dedicated testers on our scrum project. So, things aren't getting done which prevents the team from getting things "done" and limits the amount of work the developers can get done per sprint.

So, does anybody have any suggestions on helping the team move forward? Is it a matter of changing our DoD and not including UAT? If that happens, all of our testing will back up. When would we get that done and approved?

We're just stuck and I don't know what to do until we can hire more people! Any ideas are welcome.

Thanks in advance!


04:57 pm April 10, 2015

Can you explain why UAT is being conducted by an end user group rather than the team itself? Why isn't it a team responsibility to meet this part, as well as all other parts, of the Definition of Done?


05:12 pm April 10, 2015

Fair enough . . . we took it literally and wanted to have at least one actual user that could be a part of the team for UAT in case anything got lost in translation between them and the developers. As it turns out, we have 2 users involved doing that. We still wouldn't mind having 1 dedicated user doing some testing but we don't have that luxury.

That being said, we are still learning . . . is it normal to not have any users involved in the team/UAT? What do you recommend?

Thanks!


12:45 pm April 13, 2015

> ...is it normal to not have any users involved in the team/UAT?

The expectation is that "user involvement" should be rather more pre-emptive than that. There's no proscription against including users as team members, or against having UAT activities. What matters is that team members aren't constrained by skills-silos. A silo (such as doing UAT) leads to bottlenecks, the delayed detection of errors, and rework. Your team is currently experiencing those issues.

In Scrum the Development Team should work with a clear Product Owner in order to deliver each increment. The PO may liaise with users so that requirements can be understood and conveyed to the team in a timely manner, and so that waste including defects can be avoided. This includes Product Backlog refinement, Sprint Planning, and ongoing collaboration with the team and stakeholders during the Sprint. I suggest you review the PO's responsibilties in this regard.


02:07 pm April 13, 2015

Thank you, Ian! This is great info and confirms what I've been thinking. It is great to get these thoughts from a scrum veteran outside of our organization. I'm actually getting with the PO and the director over the department tomorrow to discuss a re-boot and re-evaluate how necessary it is to have the users involved at the current levels. It clearly isn't working and I hope they will see that so we can move forward! We've gotten away from "true scrum" and we need to get back! Thanks, again!


05:24 am April 30, 2015

I don't know if this adds any more value so I keep it short: In our case, we lay the options Ian mentioned on the table with each new team. And they indeed chose different approaches. Some have a PO who is very close to end users and validates for them. In some cases, the PO IS an end user. Other teams include end users from other departments into their daily work. Others work with "business enablement" teams who join the Scrum teams and validate. Some teams tried one way, it did not work out, then they changed it and it worked better. Enabling the teams to make that call and choose different approaches turned out to be the right thing.


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.