Re: UAT every iteration - cadence question
It sounds like the need you're expressing here is a couple of key internal stakeholders wishing they could give more frequent feedback. Congratulations!
What is not clear to me is whether this UAT is part of your definition of done or not. Most teams consider a backlog item to be done when the PO signs off on it. Would the PO still sign off on a story if the UAT didn't pass with flying colors? What if the key internal stakeholders who wanted to give more frequent feedback did so more frequeently, but in the end, one of the other stakeholders who gives feedback less frequently disagreed with the internal key stakeholder, what then?
I'm going to assume, based on your description, that this UAT is a part of your sign off process, and it's valuable for it to be kept as such. I'm going to further assume that you can somehow wrangle the UAT folks such that more frequent feedaback doesn't pose any extra risks(like I mentioned above). If either of those assumptions is incorrect, then you might want to ignore my advice below. :-)
Based on the assumptions, it sounds like you should consider keeping the UAT as part of the sprint cadence, vs. having it be totally independent.
Two roads to ponder:
The "Split your backlog items approach"
1. Split your backlog items smaller in a way so as to maximize the earlier feedback. Maybe these stakeholders give a lot of feedback on the UI, so front load the smaller items to emphasize the UI, etc etc. This will require some knowledge on the part of the team and UAT folks on how to split backlog items. (You didn't indicate if you're using User Stories or some other method to communicate backlog items, but there is obviously several ways to split User Stories, Use Cases, etc etc etc).
The "incorporate your UAT folks into your sprint" approach
2. Incorporate your key stakeholders into your sprint in such a way as to get earlier feedback. Maybe involve them in a piece of sprint planning or backlog grooming for future sprints, maybe hold totally separate collaborations with them, maybe add tasks to your sprint backlog to get feedback from them ("UI prototype feedback from KeyUAT folks")etc.
Questions to ask the team:
1. Do you think our sprints look like mini-waterfalls? If so, mini waterfalls is commonly known as a bad smell for Scrum teams. Does the team experience any pain from this type of situation? You could then discuss some of the perceived downfalls of Scrummerfall.
2. Do you feel it would provide value to incorporate the UAT folks into the sprint somehow? Should we do that with the definition of done? A task on the sprint backlog? Totally independent tasks or meetings with them?
3. What are the risks or costs of incorporating them earlier? Are the risks or costs acceptable to the team? How can we overcome those costs or risks?
4. Do you think a shorter sprint would help? If so, is our team ready to split backlog items smaller? Will it require some learning curve for our UAT folks to be able to sign off on what might appear to them as incomplete work but we know to be a slice of a backlog item?
Anyway, that's enough to start. I'd be happy to discuss further on-list or off. I'm nearby in Denver!
CSM and Experienced Scrum Coach
--- In firstname.lastname@example.org, Ronica Roth <ironica99@...> wrote:
> Sorry I haven't been active on these lists for a long time; I promise to
> find some questions/discussions to answer/contribute-to in return for help
> on this one. :)
> I'm working with a team new to Agile/Scrum. They are doing one month
> iterations. They spend 3 weeks doing dev & testing, then the 4th week is UAT
> (with internal stakeholders & users). They usually release after that.