First off, let me start by saying that I am a big fan of user stories. In working with teams over the years I have found that user stories are *very* helpful in ensuring that product managers, engineers, executives, and others, all keep the customer in focus when discussing new features and capabilities. It’s just too easy for folks to embellish a feature with their own ideas about what the feature should provide when they lose sight of the customer. User stories also help by focusing everyone (including customers) on the absolute minimum that is necessary in order to meet the stated needs (thus saving everyone time and effort, and allowing more time to focus on additional items instead of trying to “boil the ocean” for just one feature).
However, I believe that there are times when creating user stories to delineate and track work is not needed. Let me provide one quick example. Several years ago I was working with a team that had responsibility for a code compiler that was built to run on one platform. As new operating systems came into existence, the team was asked if they could create a version of the compiler that would run on one of the newer operating systems. Since this team was just beginning their agile adoption journey, they thought they should create a backlog of user stories for their work and estimate the stories with story points, and so they contacted me for help. Since there were no new features being built – it was just that the compiler was, in essence, being ported to another platform – I suggested that they skip creating stories since they already had a list of compiler features from their current offering and knew that the same features would need to be part of this newer version. I told them to simply use their existing list and check off the features as they were completed. This was a bit of a surprise to the team since they thought that they had to use user stories in order to “be agile.” I told them that since they already understood their customers, and completely understood what was required in the way of features, that the effort to create and size user stories would be redundant.
That being said, I did work with them to ensure that they still adopted other agile practices. In this case, they were to work on only one feature at a time, always make sure that each feature was as complete as possible before moving on to the next feature on the list, that the new compiler must actually run on the new operating system at all times as the features were being completed, and that they did not build up any technical debt (for example, by delaying fixing defects, or performance issues, etc.).
My recommendation is that if you already have a well-defined and well-understood list of items that need to be completed – for example, when repeating a list of items that have been done before – then creating a backlog of user stories is likely not needed. In these situations, if you do choose to omit the creation of user stories, please don’t omit the other agile practices such as: rank-ordering the list so that the most important items are at the top; working on – and completing – one thing at a time before moving on to the next item on the rank-ordered list; ensuring that the environment is always operational; and not piling up technical debt.
As always, please feel free to ask questions and share your experiences. We look forward to hearing from you!