8

This question already has an answer here:

I've worked in Agile environments for many years. However, one of the things that I've always felt uncomfortable about is the idea that each story should map to an end-user request.....i.e., an enhancement that is clearly visible to someone using the application.

However, a significant part of the work in real-life software engineering is done behind-the-scenes and under-the-hood. For example: switching out one ORM or DBMS for another (and the resulting code changes required); or enhancing the performance of the application via implementing more efficient data structures and algorithms; or making the application more scalable/extensible by replacing massive hard-coded if blocks with a Factory pattern; and so on.

The problem has typically been that, when I would bring these issues up in Sprint planning, product/project managers would throw out the terms "technical debt" and "refactoring" and reiterate that these things should not be the concern of Sprint planning - that instead we need to focus only on user-requested changes.

I admit that a lot of what I mentioned above could be classified as "technical debt". However, it is my experience that, when something gets classified thusly, it goes into a black hole and is forgotten amidst the never-ending torrent of user requests.

How, then, do we address this? How do we free ourselves of this tyranny? Is there a legitimate way to create stories in Agile that are not centered on things that are immediately visible to end users? And if so, how to we "word" these?

marked as duplicate by gnat, Dan Pichelman, Doc Brown, Robbie Dee, Bryan Oakley Apr 3 at 3:31

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

6

In teams I've worked on, we've always created a special person for that, called The Developer. This way, there's an Identity using the story at some point.

So, for example, we've got a story in the current Sprint related to migrating databases. The story is listed as: "As a Developer, I want to move the database from its current server to the new server so the application performs better."

While its not 'truly' agile, i've had great success with this method, as it calls out things as stuff we could work on and avoids the technical debt black hole. Additionally, it presents a business benefit to the stakeholders; They now understand in less-technical terms what the benefit of doing this work is.

  • That’s a very pragmatic and interesting practice ! – Christophe Apr 2 at 17:27
  • 1
    Improved performance is a user facing feature. – RubberDuck Apr 2 at 21:39
  • Why do you say it's not truly agile? – Bryan Oakley Apr 3 at 3:19
  • @BryanOakley I say that because the Developer identity doesn't technically gel with the idea of User stories, which are supposed to be free of technical detail. Usually, when we use this identity, we have to put something technical in the story for it to make sense. – Adam Wells Apr 3 at 13:38
  • The reason I asked is because the scrum guide and agile manifesto says nothing about a requirement for user stories. – Bryan Oakley Apr 3 at 13:56
2

Stories don't always have to be relevant to the end-user. For example

As the accountant, I want to switch to a cheaper database solution

In addition, performance and other technical issues can certainly be relevant to the end-user:

As a user, I want to execute the operation in less than 2 seconds for 90% of the cases.

Or

As a user, I want to be able to connect to the system even when there are 9000 other users connected.

Certainly, there are cases where Adam Wells' answer is appropriate, too, to use a "developer user".

Technical debt and refactoring can many times be bundled into other stories - they are mostly implementation details, after all, and invisible to the end-user as well as the PO.

  • Out of curiosity, is it your opinion that any potential refactoring/debt recovery should be part of the estimation of a story? – Adam Wells Apr 2 at 16:55
  • Not all refactoring or debt recovery. There are certainly cases where there is too much refactoring to do in even a whole sprint, so it's not feasible to include that as part of a single story. If your story is to add on to feature X, though, you want to include any refactoring necessary in feature X to allow the addition. – mmathis Apr 3 at 14:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.