I worked with a team who is used to have stories that represent the development tasks. It was a mobile application with back-end development. I explained to the team that, User Story is simply a story that is related to the system user. The developer is not a system user, he is the developer of the system. User story is the language used between product owner and development team to express valuable functionality. How is a developer technical task for the back-end be of some direct value to the customer or product owner? This representation typically break the core idea of User Story. It clearly break the famous INVEST mnemonic created by Bill Wake. The INVEST contains “V” letter, which stands for “Valuable”. Valuable by the perception of end user. The story is a vertical slice of a cake that contains all layers that compose the cake. I really like this metaphor, at least it is tasty.

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.