Team capacity planning with UAT included within sprints
Hi Experts,
Based on my experience, we have mostly worked in a 3 week sprint wherein the last day is reserved for sprint review/demo, retrospective and sprint planning for the next sprint. The team capacity is generally planned assuming 6.5 hours/day for a developer assuming rest of the time goes into bug fixing, meetings etc. A separate SIT followed by UAT cycle is run once the development is complete. Now, we have a situation where the customer wants to run a complete UAT cycle after every sprint rather than provide an acceptance after Sprint review. The challenge that I see here is that since the team will have the ongoing sprint user stories to complete along with the routine rework, there will be an additional pressure on the team to fix previous sprint issues reported by the customer during the UAT. The customer seems to be really optimistic and wants to reduce the go to market time with this approach.
Couple of areas where I would appreciate your comments/thoughts:
- How to plan ideal capacity in this case, considering that the team would also need to spend some time on UAT issues etc.
- Is there anything which we should specifically keep in mind to execute the project in such environment.
Thanks in advance!
What does the Scrum Guide have to say about the "Definition of Done"? Might an improved definition be advisable in this case?
The biggest warning sign I see here is why there is "additional pressure on the team to fix previous sprint issues reported by the customer during the UAT". I fully understand the desire of some customers to do their own UAT, for any number of reasons. The problem seems to be fixing issues.
My first question is this: Why are issues being discovered in UAT? What can be done to detect these issues during the Sprint so that the UAT goes well? It's the nature of iterative and incremental development that, once the software is released to users, they will have feedback. However, there shouldn't be any show-stopping issues. They should be able to accept the software at the end of every Sprint and see added value. Members of the Scrum Team (I'm looking at the Product Owner, but perhaps there are also other people who act as some kind of domain or user expert) should be able to represent the customer and users to point out problems or raise concerns.
My second question is this: Why is there pressure to fix issues immediately? The Scrum Master should be engaging the organization and the customer to understand Scrum. I accept that there will be feedback. However, it shouldn't interrupt the Sprint. Anything raised shouldn't be significant that it requires immediate attention in the currently ongoing Sprint. The Product Owner should be ensuring that these needs are expressed as Product Backlog Items and properly refined for upcoming Sprint Planning.
My recommendations: Ensure that you have a "Done" product at the end of every Sprint that is usable and can go through this UAT process. Your Definition of Done and Sprint Goals can help with this. If UAT is raising critical issues, figure out why and figure out how to prevent that.
Thanks for your assistance Thomas. Appreciate that.