Comments on: Expressing Technical Debt as User Stories Helps with ROI

By: www.webbiru.com

www.webbiru.com — Fri, 18 Dec 2009 20:41:45 +0000

Managing Product Development » Expressing Technical Debt as User Stories Helps with ROI…

Managing Product Development » Expressing Technical Debt as User Stories Helps with ROI…

By: Anonymous

Anonymous — Fri, 18 Dec 2009 20:40:51 +0000

Managing Product Development » Expressing Technical Debt as User Stories Helps with ROI…

Managing Product Development » Expressing Technical Debt as User Stories Helps with ROI…

By: pligg.com

pligg.com — Tue, 15 Dec 2009 20:56:06 +0000

Managing Product Development » Expressing Technical Debt as User Stories Helps with ROI…

Managing Product Development » Expressing Technical Debt as User Stories Helps with ROI…

By: Neil Murphy

Neil Murphy — Sun, 22 Nov 2009 01:16:50 +0000

I don’t really understand this post. You say you don’t like ROI as a measurement for software, but surely with your user story and the cost benefit that is precisely what you have done?

By defining things in cost benefit terms to the project as a whole you then provide the business with the information they need to make valid decisions. The use of user stories is helpful, but its not either user story OR ROI (cost benefit or whatever term you care to use).

By: Steve Berczuk

Steve Berczuk — Tue, 17 Nov 2009 19:43:00 +0000

Great post. I think that much of what I was thinking when I wrote the following was inspired by things I heard you say or write at various points in time. At the very least it validates what I’ve thought about how to fit “tech debt” into a backlog.
(http://steveberczuk.blogspot.com/2009/06/value-of-agile-infrastructure.html)

By: tieTYT

tieTYT — Wed, 04 Nov 2009 20:25:47 +0000

I like the idea, but I wish you used an additional example that is more typical. For example, there are “don’t repeat yourself” violations all over the place or a “done” but buggy part of the app is very difficult to understand.

By: johanna

johanna — Wed, 28 Oct 2009 03:44:50 +0000

Marc, your developers are also users. The business people must learn to understand the tradeoffs they make, otherwise, *they* are not managing the backlog. You are. You can. I don’t recommend it.

By: Marc Galbraith

Marc Galbraith — Wed, 28 Oct 2009 02:36:35 +0000

Hi Johanna, The team I work with likes to capture tech stories and provide and estimate. The question we keep throwing around the table is if the business is OK with the team playing the story, should we record this as an increase in our body or work (scope increase) and track with velocity or just play it without including the points in the velocity, therefore running the team at a slower velocity. The reason for these two views is that a tech story is not a business story and in the end that is all the business understands.

By: Matthias Marschall

Matthias Marschall — Thu, 22 Oct 2009 13:41:15 +0000

Thanks for the great post, Johanna.
We, too, were very successful with this approach. The team did retrospectives and added user stories for overcoming the one or two worst impediments to the top of the backlog. That way we managed to reduce our technical debt dramatically.

By: Mark Heath

Mark Heath — Thu, 22 Oct 2009 13:31:10 +0000

good post. it does require management to realise that developers are in a very real sense “users” of the codebase/build process, and the better state it is in, the more quickly and reliably user stories for the end customer can be delivered