Tuesday, August 23, 2016
I was curious to know the team motivation in doing that. I asked several questions to explore the exact meaning of why these not-valuable stories are treated that way. After listening to their answers, I got it. First, it have a size points, which gives them some credit. Second, I found that, the back-end stories are typically a preparation of next sprint stories. So, they actually break down story work into two Sprints. The first Sprint is to develop back-end code, and the second Sprint is focused on developing user interface functionality of those back-end work.
Oh my God. There are a lot of ways creative teams are able to inject the waterfall mindset into Scrum. They easily break principles and values under many weak reasons.
So, let me stress that, this is not a user story, and the way work is divided between sprints is not Scrum. The user story is meant to be totally developed in one sprint, including all required activities. In the experience described here, and in a 3 weeks Sprints, I can expect many integration bugs as well as task switching waste.
In addition to that, the Sprint velocity measure is broken. It sums valuable work of this Sprint with non-valuable back-end work of the previous Sprint. The sense of comparing Sprint velocity to another Sprint velocity or managing the scope of release backlog is broken.
To summarize, the same story has a user interface and a back end work, all should be planned to be done in the same Sprint. Exceptions are OK as they are just exception.