Handicap Indicator in Brazil


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.


Book Cover

The poll to select the next book continues.

This week we are full ahead in our re-read of L. David Marquet’s Turn the Ship Around! We continue the story of the USSN Santa Fe with Chapters 22 and 23.  These two chapters focus on how an organization’s legacy can be used to shape deliberate actions and why principles have to be tied to behavior and decisions to be useful.

Chapter 22: A Remembrance of War

The focusing question that starts this chapter is, “Do you have a rich organizational legacy?”  All organizations have a legacy. That legacy shapes its mission and its culture. Recognizing your organization’s legacy is a crucial step in addressing behavior and change.   (more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 454 features three columns!  The first is our essay and checklists on iteration planning. Aristotle stated that “well begun is half done.”  While we might argue the half part, planning is required to be well begun and that is important on any measurement scale.

Jeremy Berriault delivers a new entry in the  QA Corner.  In this installment of the QA Corner, we discuss the function of a QA Lead. Check out Jeremy’s blog at the QA Corner!

Gene Hughson anchors the cast with his Form Follows Function blog to the SPaMCAST to discuss the entry,  Trash or Treasure – What’s Your Legacy? Gene begins with the contentious topic of legacy systems.

Re-Read Saturday News

We continue re-reading The Science of Successful Organizational Change.  Steven Adams is leading this re-read.  In this week’s entry, we cover the introduction to Part 2 and chapter 3.  Gibbon’s takes us down the path of strategy and uncertainty. Remember to buy your copy.   

This week and previous installments:

Week 1: Game Plan

Week 2: Introduction   

Week 3: Failed Change

Week 4:  Introduction to Part 1 and Fragility to Change-Agility

Week 5: Governance and the Psychology of Risk


A Call To Action (more…)