Legacy?
A common question is how user stories can be developed for legacy code or for problems that crop up in production. The implication is that creating user stories is too hard when dealing with legacy code changes or too slow when dealing with production problems. User stories are a core tenet for most agile approaches. User stories are a vehicle to capture nascent needs and wants in a brief container, a card. Those needs require the parties to interact and converse in order to refine those needs into something so the need can be transformed, a conversation. During the conversation, as the understanding evolves, the team learns how they will prove that they meet the need, confirmation. In our series “Agile, Where Agile Fears to Tread” we established how we can use agile techniques for both legacy (mainframe being used as a proxy for all legacy code bases) and for maintenance. There are a lot of reasons why some practitioners resist user stories in these two are areas.
For example, determining who the user is for legacy functionality—especially backend functionality—might be difficult. The classic format of a user story is “persona, goal, benefit”. The persona is the user; the person that will use the functionality. While everyone can and should write user stories, product owners are often solely tasked with the role and those serving legacy systems are often proxy product owners that are not close to the business. This arrangement leads legacy teams to need to lean on more classic requirements documents and use cases with reviews and signoffs to ensure a conversation. Legacy applications often are core to the organization’s mission and are often large. The list of work required to add and enhance new features is long. Long backlogs tend to be hard to groom and prioritize, meaning that the backlog is a place for ideas to die or a place to entice people to jump the queue.
The reasons user stories are difficult for maintenance are both similar and very different than for legacy applications. The most often quoted reasons why user stories don’t fit into the maintenance flow of work is the belief that framing the problem by identifying who is affected, what they want to be fixed and why they want it fixed takes to long. I will let that statement just sit there. Maintenance is often different from legacy work, especially correcting defects because the user is often the one that reported the problem. In large organizations, the backlog of maintenance work and small enhancements (often masquerading as bugs) can be long and fall prey to the same grooming and prioritization issue as legacy applications. Finally, many firms outsource maintenance support and the people doing the work are removed from deep knowledge of the business and therefore have a difficult time framing user stories including acceptance criteria.
A common problem in both scenarios (but thankfully less often every year), is that legacy and maintenance personnel are required to follow structured, gated, waterfall or, worse, ad-hoc processes. Whether the reason is familiarity with these approaches, security or contractual reasons the staged or random approaches are less friendly to using user stories.
My knee-jerk reaction to why user stories don’t fit is a retort with a barbed tongue. This is where it is good that my mouth and lizard brain have a filter between them because it would be easy to ask whether the person asking wants to create a requirements document to sign off before getting any feedback or would just rather start to code before considering what the change should do. Realistically, neither make sense and I am pretty sure that is not the intent of the question. Next, we explore ideas for making user stories fit.
Software Process and Measurement 