Total story point planned vs done
We just transform from waterfall to agile not too long ago. We used to have UAT session and the users only test when they are available, and we must wait for their sign off before we release to the production. Our release is also scheduled once a month.
Since we started agile, the UAT process is remain the same, as users are not ready to participate in our agile process. Release still remain once a month because of existing governance process still remain.
Our sprint duration is 2 weeks, we plan average 50 points per sprint, and the actual completed points is average 25.
Which mean average 25 points carry forward to the next sprint. However, out of these 25 points we have about 20 points in the UAT pending for user to perform testing. If we assume our velocity is 25 points, we can't get any new story added to our sprint, but in fact we are available as we are not working on those 20 points UAT story, but just standing by for the UAT.
Therefore, we added another 25 points in the sprint during the planning. Also, we often start our story in the mid / end of sprint, however, these story is usually partially done and carry forward to next sprint.
When we're doing this sprint after sprint, the total planned story points is always 50% more than our velocity. It doesn't seem right but I'm not sure what should we change? Any advice?
One of the most important things to understand about Scrum is that a "Done Increment is required by the end of the Sprint. If UAT is required for the Increment to release and it sounds like it is, you're not there yet. If you're doing UAT in another Sprint, you're not doing Scrum as this is more like Waterfall.
Consider this a major impediment to work though rather than focusing on story points. Your velocity is actually zero if you don't have a "Done", potentially shipable Increment by the end of the Sprint.
Changing Scrum because the users are not ready won't get you the change you really need.
Our sprint duration is 2 weeks
I'd suggest that, in reality, it isn't. You observe a release schedule of one month. Therefore the ability of the team to inspect and adapt based on empirical evidence cannot possibly be less than a month.
If it were to take longer than a month to build a fully tested and Done increment, then the feedback loop would become attenuated. A Sprint must be one month or less, and each increment must be fit for immediate release.
My advice is to frame your challenge in these terms, and to forget about story point accountancy.
Although I agree with Chris's statement that "changing Scrum because the users are not ready won't get you the change you really need", I have a slightly different way of looking at this.
Why did your UAT process remain the same as you transformed to Agile? Or, alternatively, what is the purpose of the UAT process in your Agile environment?
For me, UAT is validation - confirmation that the thing that you have designed and built meets the need for a particular intended use. It is not a place to find problems - misunderstood requirements or needs, mistakes or bugs, or any other problems. Validation should be a formality or the last opportunity for your users to reduce the risk of accepting a new Increment into their working environment.
I don't believe that a development team or a development organization should be constrained by what happens outside of the development team or the development organization. In most cases, users are outside of the development team or development organization.
My current thinking is that the Scrum Team should be able to take any "done" Increment, which is produced at least one per Sprint, and be able to present that into a UAT or otherwise release for broad use at any point in time. In an ideal environment, a UAT would not result in any "showstopping" findings but may generate information that the Product Owner can use in Product Backlog management. I would suggest that "showstopping" findings should be looked at by a team, perhaps in a Sprint Retrospective, to determine why the issue was not detected and corrected prior to a UAT.
The workflow for the team would end when work is "ready for UAT". You can continue to track it into UAT and then into a finalized release and deployment if necessary. But I would strongly consider that "Done" and "ready for UAT" are an equivalent state and that most, if not all UATs, result in acceptance.
Thanks Chris, Ian and Thomas for your valuable advice.
I agree we need to think and explore these questions. Are we not ready for scrum yet? Should we change our sprint duration to fit with our monthly release? Should we change definition of done to ready for UAT?
There're also some other doubts and challenges which I just post in another topic.