User Acceptance not being completed within a Sprint.
I am taking over a new team, and the team is asking to move to 3 week sprints, because they cannot meet the "DOD" of the stories within the 2 weeks sprint. The stories cannot be broken down smaller, and they can complete Dev and testing, but the UAT is done by the Business and due to lack of availability, it can never seem to happen in the sprint. What would you do?
Assumption: Definition of done includes that all stories / PBI's are complete when acceptance criteria has been met. (UAT is part of acceptance criteria)
Please let me know your thoughts?
In Scrum a Development Team should be fully cross-functional, and have *all* of the skills and resources needed to create a "Done" increment of release quality no later than the end of each Sprint. No-one can force or otherwise oblige a team to take on work which they are unable to complete.
In the situation you describe, a Development Team would be within their rights to refuse that work where UAT must be done by another party, and they may be seen as having a professional obligation to do so. Ways forward include:
- The team might offer to do UAT themselves, perhaps by being cross-trained accordingly;
- Incorporate a business representative in the team with UAT skills
- Have business nominate a trusted champion on the team who can do UAT to the standard required
What are the team's thoughts about how they can best meet the Definition of Done?
Like most companies who want to be scrum, but are not there yet, We have certain standards and limitations that prevent us from making a purely "Scrum" decision. The team wanted to change the definition of done to state that the user story is complete when it has been developed (DEV), tested (ITO) and delivered to the Business. Since UAT is done outside of our Team and cannot be incorporated into the sprint, the team feels like they have met their obligation to deliver a potentially shippable item.
Ian,
By "standards and limitations", you mean "impediments to Scrum", yes? ;-)
It is a terrible idea, and a very slippery slope, to view sprints as workflow stages of delivery. The question to ask and try to resolve is how to incorporate UAT within the sprint. Without remedying that issue, your Scrum practice is being set up for failure.
Scrum does a great job raising visibility of the inefficiencies and impediments in your current process. Fix them, and you'll reap the benefits. Ignore them, and you'll continue doing the same things, only expecting the label "Scrum" to magically make things better.
Very interesting that your Development Team wanted to change the DoD to reflect how they've previously worked, instead of changing how they work. Don't sweep this under the rug. It is a problem - try and figure out how to solve it.
I think you know the actual root problem, but you seem to have accepted these limitations.
Don't.
I would also be highly critical of the US can't split smaller point of view. Maybe it's true, most often it's not.
Perhaps look at getting your team some training in Behavioral Driven Development (BDD), so they they are cross functional enough to complete UAT themselves.