ISerialized .Net, C#, Scrum and agile software development

Features vs. user stories in Scrum

As Scrum has grown in popularity, the concept of user stories has made its way from theory and dust covered UML books, to developers every-day vocabulary.  In the "old days" we tended to focus on one layer at a time, instead of one user story at a time, we focused on writing large classes supposed to solve all possible scenarios for later re-use instead of simple YAGNI focused classes pin-pointing its purpose  and we focused on large-upfront design instead of gradually adapting to the maturity obtained by the customer (and developers) through the project.

We started out with allot of user-stories and even more good intentions, but ended up with phase 2 and 3 and a bunch of long forgotten concepts and diagrams. Today we are not better at planning one year ahead; we have just realized that this is almost impossible. We started focusing on business value which closely relates to user-stories. We started working with user stories weekly and we started estimating and prioritizing user stories in our Product Backlogs.

On a customer project where I have been working with Scrum for a long time, we suddenly had a shift from smaller well-defined feature requests to requests for larger conceptual changes. We continued with the same approach to our customer requests, but we had several indications that we were missing something:

• One product backlog item spans more than one sprint
• Large number of work items per product backlog item/user story
• Difficult to keep track on break down
• Slow down in velocity near sprint end
• Hard to define a clear DoD "Definition of Done"
• Estimate slides

I suddenly felt that here had to be something missing, why did we suddenly start bumping into these problems? The answer is very simple: We had mixed up the concepts of features and user stories/product backlog items. For smaller feature requests, the concepts have a more theoretical than practical difference, but for larger feature requests, both concepts are necessary to be able to break down and estimate the full job.

Differences and similarities:

• We deliver features to our customers, not user stories
• Features can be tested by the end-users, user stories is not necessarily fully testable for the end-user. In many cases testing a user-story until fully integrated with the rest of the feature might only make sense to the developer. Eg. testing a credit card validation in an online shop makes little sense to the end user unless he can also add items to a shopping cart and proceed to checkout.
• A feature can span several sprints, one user story should never span more than one sprint, it only indicates you're missing granularity in your user stories
• One feature can contain several user stories

Try to always think of these two concepts as two separate things: All requests from you customer is most likely a feature request, not one well defined user story ready for work breakdown!

About Paul Eie

My name is Pål Eie (English alias: Paul Eie) I'm an IT consultant working in Stavanger, Norway. My experience spans from AIX to Windows and from embedded C to Uniface, Java, C++ and C#. My blog will involve everything that is related to technology. As long as it might be of interest to either newbies or seniors, I will blog about it! If you find some of my posts about basic old technology, it just means you know more than many of my other readers!